KOMPLETE coming soon :-))

MODULAR MINI 2
erste Testphase (Funktionalität aller Module) beendet
zweite Testphase (Erstellen und Optimieren von Snaps) startet nun

ciao herw

 

der server zeigt den thread mal wieder nur teilweise oder nach mehrmaligem Nachladen der Seite etwas an

ciao herw

 

screenshot modular mini II

psychedelisch! bunt!
warst Du etwa auf der "summer of love" ausstellung in frankfurt?
http://www.schirn-kunsthalle.de/

 

Man(n) darf gespannt sein

 

Re: screenshot modular mini II

nunja bei dieser Art Drehknöpfe muss man sich irgendwann einmal für eine Farbskala entscheiden. Ich habe Drehknöpfe in 36 Farbtönen. Eine dezente Abtönung innerhalb einer engen Farbskala hat mir nicht so gefallen. Ich hoffe, dass man durch die Farben schnelleren Zugriff auf bestimmte Parameter hat. Aber wie gesagt, das kann man ja beliebig ändern, da in dem Ensemble sehr viele tga-Files vorliegen und alle Drehknöpfe quasi dasselbe tga-File benutzen.
Außerdem wollte ich mich von dem Einheitsgrau manch anderer Ensembles absetzen.
Das wichtigste ist aber der Klang. Ich pirsche mich erst ganz vorsichtig an die Patches heran. Die Vielfalt der Verbindungsmöglichkeiten ist schon verwirrend. Wichtig ist vor allem die Archivierung der Patches. Im Moment mache ich neben dem sortierten Abspeichern auch manchmal einen Bildschirmausdruck. Bei noch mehr Racks wird es allerdings wohl schon etwas unübersichtlich, so dass ich mir da noch etwas anderes überlegen muss.
Das Keyboard ist ein Sahnestück und basiert auf den virtual keys benutzt aber im Gegensatz zum Original eine mouse area statt eines multipictures. Dies bringt den Vorteil, dass man mit der Maus nun schnellere Repetitionen ausführen kann. Die Abfrage der Mouse-Area konnte nochmals vereinfacht werden.
Ich teste das Ensemble jeden Tag. Gestern kamen 10 Classic-Orgel-Patches hinzu. Im Bassbereich ist der Klang sehr satt bei vier Oszillatoren.

ciao herw

 

Und was machen die ganzen Strippen auf der Abbildung? Hab ich was verpasst, oder kann man Wires jetzt direkt auf der Ensembleebene ziehen?? Hatte ich früher schon mal vorgeschlagen, da verwies man mich jedoch auf die Send und Receive-Module. Damit gab bzw. gebe ich mich derzeit auch zufrieden wobei es nicht das gleiche ist wie Strippen direkt ziehen zu können.
Direktes ziehen würde einem nicht nur die umständliche Organisation der Send- und Receive-Module ersparen...

lg

 

guckst Du hier: MODULAR MINI 1 )
Das Strippen-Ziehen und Verknüpfen ist wirklich auf dem Panel möglich und funktioniert perfekt. CTRL-Click auf Ausgang und Eingang eines Moduls schafft optisch und strukturell eine Verbindung. Doppel-click löscht die Verbindung. Alle (!) Eingänge können mit allen (!) Ausgängen verbunden werden - keine Pull-Down-Menus, keine Matrix - alles nur durch Mausklick wie im richtigen Leben.

ciao herw

 

Nicht dein ernst?! Und jede Verkaplung wird dann mit dem Snap abgespeichert?? Anders wäre es es ja unbrauchbar! Im Normalfall wäre gleich testen angesagt, aber heute komme ich wohl nicht mehr dazu :'(

lg

 

mein voller Ernst! Allerdings brauchst Du REAKTOR 5.
Die Verbindungen erfolgen übrigens tatsächlich über internal connections, organisieren sich aber selbst, da ich sowohl mit IC-send und normalen receive Modulen arbeite. Auf der Oberfläche wird dann mit Hilfe eines Mouse area Modules die Mausposition und Aktion erfasst und dann als Befehl an ein IC-Send-Modul übergeben. Dort wird dann mit Hilfe der IC-send modules ein Schaltbefehl an das Receive Modul weitergereicht, so dass die Signalverbindung aufgebaut wird. Parallel dazu werden die beiden Mauspositionen (Eingang - Ausgang) ans Multidisplay weitergegeben, das dann die Kabelverbindung auf den Bildschirm abbildet. Da die Ein- und Ausgänge jeweils mit snapshot- Modulen (wie alle anderen Bedienelemente auch) verbunden sind, wird sowohl die Verknüpfung wie auch die Grafik für jeden Snapshot abgespeichert.
ciao herw

 

Hab dein Ensemble mal kurz ausprobiert, aber autsch - was ist das?? Teileweise tauchen radikale Artefakte während eines Snapshotwechsels auf. Meine armen Boxen!

Und die CPU-Last ist für dieses kleine Gerät auch ziemlich hoch, wobei das noch sehr milde ausgedrückt ist.

 

Das wundert mich sehr. Bisher hat noch niemand irgendwelche Fehler gemeldet bei über 1000 downloads. Ich habe einen ausführlichen Beta-Test durchführen lassen (Phil Durrant).
Die Performance ist hervorragend (Mac Powerbook 12' 877 MHz bei 6 Stimmen maximal 50%, Mac Dual 2,7 GHz bei 6 Stimmen maximal 18%).
Seit Monaten arbeitet das Ensemble ohne jeglichen Fehler sowohl grafisch wie auch soundmäßig.
Hast Du den Hinweis im Handbuch gelesen (Extra-Download). Du darfst auf gar keinen Fall Eingriff in die Struktur nehmen, insbesondere keine Module löschen oder austauschen. Das ist zwar möglich, erfordert aber ein hohes Maß an Einblick in die Funktionsweise.
Beim Umschalten von manchen Snaps muss man wie bei allen Ensembles darauf achten, dass eine Initialisierung stattfindet. Dies ergibt bei großen Delays leider einen Peek, den man nicht unterdrücken kann. Dies passiert aber nur sehr selten. Um dies zu vermeiden, sollte man das Delay erst herunterregeln und dann umschalten. Falls dich das stört, kannst Du natürlich auch durch den OFF-Schalter das Delay immer umgehen und in einem Host dann ein Delay dazuladen.
Modular Mini 2 ist mehr als doppelt so groß. Und arbeitet ebenfalls problemlos. Grafikprobleme gab es schon seit Monaten nicht mehr obwohl ich schon mit der dreifachen Größe arbeite.

Prüfe nochmals das Ensemble und beschreibe den Fehler bitte genauer.
Schade, dass deine Erwartung dadurch so gedämpft ist, aber ich denke die Ursache werden wir schon herausfinden.
Zur Sicherheit habe ich auch nochmals das Ensemble aus der Library downgeloaded - alles ist ohne Fehler.

ciao herw

PS: morphing geht natürlich nicht (ist zwar witzig anzuschauen), gibt aber keinen sinnvollen Soundwechsel.

 

Ja ich bin wohl auch der erste der sich nach keinen zwei Minuten testen schon ein Kommentar erlaubt ^^ Das mit der CPU-Last will revidiert sein, sorry nichts für ungut. Aber das mit den Artefakten ist nicht normal, das kannst du mir so nicht weiß machen! Selbst wenn kein Sound erklingt (klar wenn ich während der Soundwiedergabe Snaps wechsle kann so was schon mal vorkommen), ja selbst wenn ich noch nicht einmal irgendeine Taste berührt habe und bspw. die Nr. 41-Floete wähle treten diese grausamen Artefakte auf. Und schau dir dabei mal den Pegel an!! Delay runter regeln nützt dar gar nichts nur der Off-Schalter. Aber das ist ja auch nicht Sinn und Zweck der Sache! Also von weitern Test werde ich gerne absehen, weil mir meine Anlage dafür zu schade ist (Das ist ein Problem die die User-Library mit sich bringt. Man weiß nie welch zerstörerische Ensembles sie birgt. Da analysiere ich in der Regel lieber offizielle Ensembles wie z.B. Photone.)

Aber dennoch interessiert es mich wie du das mit den Wires genau hinbekommen hast, also ganz ohne ist solch eine Verknüpfung ja doch nicht. Auch die Regler beeindrucken mich! Leider hast du alles über Core erstellt und da hab ich mich noch gar nicht eingearbeitet, also werd ich es wohl erst mal aufschieben...

lg

 

ja diese Artefakte sind beim Wechsel auf "Flöte" etwas eigentümlich. Das habe ich auch noch nicht ganz herausbekommen. Zuerst habe ich vermutet, dass es eventuell am Patch liegt (Audiosignal in SCA -> Filter -> Delay) wobei das Filter durch einen kurzen Peek zur Eigenschwingung angeregt wird. Bei anderen Patches, die diese Reihenfolge ebenfalls benutzen, traten aber keine Artefakte auf.
Generell muss man bei einem Modular-Synthesizer (auch Hardware-Synthesizer) immer vorsichtig sein, was man mit wem verbindet. Auch wenn alle Verbindungen möglich sind, so können sich manche Effekte so hoch schwingen, dass sie außer Kontrolle geraten. Ich erstelle also - vor allem neue Patches - immer sehr vorsichtig und zunächst bei sehr geringem Pegel. Über den Flötenpatch bin ich selbst etwas unglücklich, da ich das Ensemble perfekt haben möchte.
Ich habe die Frage auch schon ins englische Forum gestellt, doch keiner hat je darauf geantwortet und ähnliche Anfragen von anderen, die in dieselbe Richtung zielten, wurden nur mit einem virtuellen Achselzucken beantwortet.
Das Problem der modularen Synthesizer ist generell, dass man neue Verbindungen knüpfen muss und damit auf jeden Fall eine Initialisierung erfolgt. Dieses Umschalten (egal ob mit echten Switches oder mit receive-Modulen) scheint diese Artefakte zu erzeugen.

Du sagst leider nichts mehr über die grafische Darstellung; die scheint ja wohl jetzt im zweiten Test zu funktionieren?
Die Verknüpfung über IC-Send geht davon aus, dass es sich bei den normalen receive-Modulen um ganz normale Schalter handelt (man kann ja ein Menu aufrufen). Diese Receive-Module lassen sich aber nicht nur per Maus schalten sondern können durch ein IC-Send-Module geschaltet werden also zum Beispiel durch den Aufruf einer Schalterstellung mit einer Nummer. Ich habe sehr lange Versuche dazu gemacht, ursprünglich sogar in R4; auch dort konnte man dasselbe Prinzip durchführen (etwas umständlich mit den Sendmodulen und anderen internen connections). Dann stand aber nicht so eine einfache Grafik zur Verfügung; es wären tausende von Bildern nötig gewesen, um die Wires darzustellen. Die Receive-Module haben gegenüber den normalen Schaltern den Vorteil, dass sie nicht auf die Zahl von 40 möglichen Signalquellen beschränkt sind. Bei den Versuchen dazu ergab sich leider, dass die Zählweise der Schalterstellung immer rückwärts erfolgt; ich weiß nicht, warum das NI so gemacht hat, aber da muss man erstmal darauf kommen.
Wenn du mal in die Struktur des Racks schaust, wirst du erkennen, dass dort zum Beispiel Infomationen wie die Anzahl der Eingänge und Ausgänge und deren Koordinaten weitergegeben werden. Dem gesamten Rack unterliegt ein Raster, so dass jeder Eingang und Ausgang eindeutig in einem Koordinatensystem beschrieben werden kann. Dieses Raster ist viel gröber als die Grafikauflösung. Bei jedem Erstellen eines Wires werden die Koordinaten der gewählten Buchse und dessen Nummer weitergegeben. Aus der Ausgangsnummer wird für den gewählten Eingang die Schalterposition errechnet. Die Koordinaten wiederum werden an das Grafikmodul weitergegeben, das die groben Rasterkoordinaten in die Grafikkoordinaten umrechnet und dann vom Mittelpunkt der jeweiligen Start und Zielpunkte je sechzehn Linien zeichnet, so dass jedes Wire ein 4 Pixel-Strich ist. D.h. jedes Wire besteht aus 16 feinen Linien. Wenn du von der Struktur des Grafik-Makros zum Panel wechselst, wirst Du bemerken, dass die Wires nun oberhalb der Bedienelemente liegen und man keinen Zugriff auf diese hat. Das liegt leider an der Verwaltung verschiedener Grafikebenen von REAKTOR. Normalerweise schaut man ja in der Struktur nicht nach. Da die Wire-Grafik kleiner ist als das Rack, genügt ein Mausklick auf die Überschriften der Module und man hat wieder das Rack als oberste Ebene aktiviert (die Wire liegen dann wieder unter den Bedienelementen und sind zugänglich).
Bei einem so umfangreichen und Zeit intensiven Projekt lassen sich nicht alle möglich Konflikte voraussehen (die Artefakte sind so ein Konflikt). Im Moment muss ich damit leben. Da ich MODULAR MINI nicht live benutze, sondern eher an Cubase denke, ist das Umschalten vermeidbar oder eher in seinen Wirkungen vorhersehbar. Einen Hardware-Modular-Synthesizer müsste man erstmal umständlich neu programmieren. Einzig der NORD-MODULAR kann da mithalten; dafür halte ich - unabhängig von meinem Ensemble - die Soundqualität des NORD-MODULAR für etwas dünn und Arturias Modular ist für mich eine einzige Enttäuschung. Dort ist der CPU-Verbrauch nun wirklich sehr hoch.
Viele Makros enthalten kleine Tricks, um die Pflege des Systems möglichst einfach zu halten. Die Module sind alle genormt, wie du unschwer erkennen kannst. Diese Normierung habe ich auch in der neuen Version einhalten können. Das Konzept hat sich also als voll tauglich für ein größeres System erwiesen.
Die neuen Panelelemente haben im Modular-Mini Eigenschaften, die die NI-Regler nicht haben.
In der Version MM2 basieren alle Bedienelemente nur noch auf mouse ares und die Anzeige erfolgt über Multipictures. Auch dort gab es ungwohntes Verhalten bei der Initialisierung (beim Ein- und Ausschalten des Ensembles sprangen die Mehrfachregler und die Zahlanzeigen z.B. auf falsche Nullpositionen zurück). Ich habe allein dafür zwei volle Tage gebraucht, um diesen Fehler auszumerzen.
Ich habe bewusst soviel EventCore-Zellen wie möglich benutzt, da man dann nicht auf die Verarbeitungsreihenfolge achten muss und man doppelte Berechnungen vermeidet, was in experimentellen Versionen oft zu Fehlinterpretationen der Grafik führte und nur durch unzählige Value-Module unterbunden werden konnte.
Auch die IC-Send module sind schwierig zu handhaben. Zum Beispiel senden sie nur dann Events, wenn sie sich unterscheiden. Das ist aber nicht immer erwünscht, also habe ich jeden Trigger-Event erst in einen Gate-Event verwandelt und musste ihn beim Empfang im Receive-Modul und im Grafik-Makro wieder in einen Trigger zurückverwandeln. Die Grafikbefehle des Multidisplay müssen in einer bestimmten Reihenfolge angesteuert werden. Alles sehr kompliziert und nur durch lange Studien herauszufinden .... und und und.

Ich bin froh, glücklich und stolz so weit gekommen zu sein. Mein Traum eines echten Moog-Synthesizers kann ich mir nun wenigstens teilweise erfüllen; auch wenn es vielleicht an manchen Ecken noch hapert. Wenn ich mir allerdings vorstelle, mit welchen Problemen Bob Moog zu Beginn zu kämpfen hatte (Stimmstabilität der Oszialltoren) und auch heutzutage ein echtes Modularsystem noch mindestens 20 Minuten aufgewärmt werden muss, dann bin ich doch zufrieden.

Wenn jemand eine Idee hat, wie man die Artefakte vermeiden kann; ich bin ganz Ohr.

ciao herw

 

ich denke die grenzen sind da eher fließend.
zudem gibt es immer noch einen mastervolume regler (oder einen limiter).

 

Na sauber, da zeigt doch mal wer Einsatz! ^^

Aber wie kommst du darauf, dass ich was an der Grafischen Oberfläche auszusetzen hätte? Das hat der Herr sich dann wohl eingebildet. Grafik ist OK und Wire-Verknüpfungen funktionieren (Beim PC allerdings mittels der rechten Maustaste)!

Das ist auch so ne Sache für sich, man muss sich erst einmal mit den Programmcharaktere auseinander setzten und im schlimmsten Fall darf man das nach jedem Update wiederholen. Hast du mal dran gedacht C++ oder so zu lernen?

Na wie auch immer... ich arbeite auch gerade an einem modularen Synthesizer. Die ersten Macro-Prototypen stehen soweit, nun bin ich genau an dem Punkt an dem ich mir überlegen muss wie ich das ganze verschalte... Die Problematik bei Puldown-Menüs ist halt eben die Unübersichtlichkeit welche bei umfangreichen Verschaltungen entsteht! Und die Problematik einer Matrix brauche ich hier gar nicht erst zu erwähnen, oder?! Dein Strippen ziehen stellt da echt ne Alternative dar aufzubauen (wobei sie mit zunehmender Komplexität auch nicht übersichtlicher wird), jedoch ist sie etwas umständlich. Das müsste einfacher gehen. Am besten wäre ja NI integriert eine derartige Funktion serienmäßig! (Gibts eigentlich schon nen Thread mit Verbesserungsvorschlägen und Anregungen, also hier im Deutschen Forum?!)

Was die Grafik angeht gebe ich mir da nicht so viel Mühe wie du, hab ich früher mal Wert drauf gelegt, mittlerweile zählt nur noch der Sound der Raus kommt (Übersichtlich muss es aber natürlich schon sein!). Im Prinzip lasse ich auch keine Regler-Pictures anzeigen. Einzig die Werte, welche man ja auch Regeln kann. Auf meinen Oberflächen sieht man also nur Zahlen, eine Menge Zahlen

Nach meinem Zeitplan müsste ich die Version 1 so in zwei Monaten fertig haben, ich kann dich dann gerne wissen lassen wie sich mein Synthi verhält. Er wird für den Anfang 3 OSCs, 2 LFOs, 2 Hüllkurven, 2 Filter und diverse Effekte beinhalten. Die Effekte übernehme ich vorerst aus bereits bestehenden Ensembles, da hab ich mich aber noch nicht speziell festgelegt. Was die Filter angeht kommen ein paar ausgewählte aus Photone zum Einsatz. Ich liebe Photone, die Sounds sind genial, aber leider ist das Instrument für den praktischen Einsatz so gut wie unbrauchbar, da es zum einen von der Bedienung her zu gestaucht ist und man zum anderen keine Reglerbewegungen (bis auf je einen) direkt aufzeichnen kann. Schade!! Mike sollte dieses Instrument unter R5 neu aufsetzen!!


Danke für deine Mühe!

grüßle

------

P.s. Also der Snap 73 Zisch und 88 Wind hauen auch noch gut rein! Autsch autsch. Konnte allerdings feststellen, dass dieses Problem nur auftritt wenn du von einer bestehenden Verkabelung aus zu diesen wechselst! Nimmst du als Ausgangspunkt einen Snap ohne Verkabelung sind sie unproblematisch! Vielleicht hilft das ja weiter.

...

Haha, da hat er die Resonanz mit nem Audio-Clipper gecutet. Du Sünder! Verrate mir wie ich dir Bilder zukommen lassen kann und ich zeig dir ne Eventvariante. Ist zwar nicht von mir, aber sie funktioniert! ^^

So jetzt geh ich aber schlafen. gutes!

 

Missverständnis meinerseits

Handbuch zum Modular Mini schon gelesen?

Ich habe vor zehn Jahren entschieden dass ich nach Algol, Basic, Fortran, USCD, TurboPascal, Prolog, Modulo und OOP mit TurboPascal und Delphi keine Lust mehr habe, mich in C++ einzuarbeiten und überhaupt noch zu programmieren. Das ist für einen Laien wie mich zu zeitaufwendig.

nämlich? Aber unabhängig davon war mit dem Modular der Wunsch und das Konzept verbunden genau diese Strippen und den Aufbau eines Hardware Modulars zu emulieren.

naja dann kann ich mich ja in den Sessel lehnen und noch fünf Jahre warten. Der Reiz besteht für mich gerade darin aus den gegebenen Bedingungen möglichst viel und möglichst interessantes herauszuholen. Wenn Ni eine solche Möglichkeit zur Verfügung stellen würde, dann würde ich erwarten, dass schon ein fertiges VST vorher angeboten wird. Aber manchmal kann man es auch besser machen, zum Beispiel ist das Keyboard in MM2 mit Glissando und Velocity, was die NI-Keyboard bisher alle noch nicht können (mit Ausnahme von Absynth das dann aber nicht so schön aussieht). Da hätte man auch fragen können, warum NI so etwas nicht anbietet. Wozu? Es geht doch!

gerne

Das erwähnte ich bereits in der obigen post

Vielleicht solltest Du Dir bei deinen Wertungen über einzelne Makros und Module etwas mehr Zeit nehmen, warum manche Bauabschnitte gerade so aufgebaut sind.
Das Modular Projekt besteht seit gut 1,5 Jahren. Die ersten drei Monate habe ich nur damit verbracht, mit Bleistift und Papier das Gesamtkonzept aufzustellen. Die konkreten Module haben mich damals noch gar nicht interessiert. Das Prinzip eines Hardware Modulars ist, dass alle (!) Ausgänge mit allen Eingängen verbunden werden dürfen (!). Abgesehen davon, dass das Risiko, dass manche ungewollte Reaktionen im Klangverhalten und in der Funktionsweise überraschend auftreten, nicht für alle Situationen vorhersehbar ist. Aber bedenke, dass jeder Eingang mit Audiosignalen gefüttert werden darf. Der angesprochene Clipper ist bewusst als Audio-Clipper gewählt, da ich ein Audiosignal am Eingang erwarte. Hinter dem Clipper erfolgt ein Übergang zu einem Eventeingang eines Primary-Level Filters. Da NI aber auch CoreCell-Filter anbietet und ich diese auf Dauer alle einsetzen werde, ist ein AudioClipper sinnvoll. Übrigens haben die Hüllkurven der CoreCell-Library, die ich benutze, Audioausgänge. Oder möchtest Du auch noch darauf achten müssen, dass manche Eingänge eventuell nur Event-Signale erwarten? Das hieße ja, übertragen auf Hardware, dass ich die Universalität einer einheitlichen Spannung aufgebe.
Ich habe mir sehr lange und sehr viele Gedanken zu jeder Kleinigkeit gemacht im Hinblick auf ein großes Modularsystem; und ich meine damit groß und nicht nur drei Oszillatoren, zwei Filter, zwei Verstärker etc. ich meine groß: neun Oszillatoren, sechs Filter, diverse Verstärker mehrere Hüllkurvenarten, Ringmodulatoren, Chorus, Flanger, Tubolator , Delay, Mixer, 4 LFO, SLFOs, Synchronisation, physical modelling, sampler, sequenzer etc.
Wenn ich mich da nicht an diversen wichtigen Stellen für bestimmte Konzepte entscheide (wie zum Beispiel generelle Wahl von Audiosignalen), dann komme ich aus der Experimentierphase niemals heraus.
Aber nun will ich aufhören und mich mit der Unterdrückung der Artefakte beschäftigen; ich habe da eine Idee.

ciao herw

 

OK, mach das mal, und viel Spaß!!

Später dann mal Bock auf nen Soundcontest, mein Synth gegen deinen - (allerdings nur wenn ich die Zeit finde)

-------
Edit

Ja jetzt Sorry hab gestern echt nicht so viel Zeit mitgebracht!


Aber nochmals, das mit den Kabeln ist genial!!! Wenn ich ganz durchgeblickt habe werde ich das dankend in meinen Projekten übernehmen! Weiter so!

-------
Edit

Aber natürlich! auch ein Danke an NI! Es dauert nicht mehr lange und ich fange an euch zu vergöttern und zu huldigen ^^

Wenn man sich die Beschreibung des MultiDisplays so durchliest könnte man fast meinen, dass es u.a. genau für solche Anwendungen gedacht ist Also ich verliebe mich von Tag zu Tag mehr in den Reaktor! Mit Version 5 ist er wirklich langsam erwachen geworden. Was da noch alles kommen mag?


Respekt und Greatz

 

herw, deine Berechnung „Anzahl der Objekte / Linien pro Kabel = Kabelanzahl“ funzt irgendwo nicht ganz. Setze beispielsweise mal die Anzahl auf 320, das müsste dann nach Adam Riese 20 Kabel machen, jedoch erreicht man die nicht. Bin auf ca. 17 gekommen und was noch schlimmer ist. Probier mal eine der OSC-Wellenformen auf den SCF-Pitch-Eingang zu setzen! Das Wire wird dann gar nicht mehr angezeigt!
Wobei dieses Phänomen scheinbar zu vernachlässigen ist, sofern man einfach darauf achtet, dass das Display mehr als genug Objekte abbilden kann, wollen wir das zumindest hoffen, denn ein irgendwo rum hängendes unsichtbares Kabel wäre manchmal vielleicht nicht so toll.

 

Lieber Firedragon,
ich habe Dir schon in der vorangehenden Post gesagt, dass man zum jetzigen Zeitpunkt keine Eingriffe in die Struktur ohne ausreichende Kenntnisse vornehmen kann. Sonst hätte ich schon längst ein entsprechendes Leer- und Lehr-Ensemble angeboten. Es ist ist nicht so, dass die Darstellung der Kabel nur von der Anzahl der Speicherplätze des Multi-Displays und des Snap-Value-Array abhängt. Ich habe schon vorher erwähnt, dass die Eingänge sich teilweise selbst verwalten. D.h. die Übergabe zum Beispiel der Gesamtzahl der Eingänge und Ausgänge errechnet sich selbst, um die Organisation der Receive-Schaltermöglichkeiten möglichst gering zu halten. Sonst muss man bei jedem Ensemble wieder alles von Hand ändern. Du hast die Zahl der möglichen Kabel auf 20 reduziert. Das System geht aber nach wie vor von der höheren Anzahl der Eingänge aus. Dadurch kommt es natürlich zwangsläufig zu einem Konflikt.
Wenn Dich diese Art der "Schalttechnik" interessiert, dann rate ich Dir, zunächst mit einem kleinen eigenen Testaufbau (z.B. 4 Ausgänge werden mit vier Eingängen per IC-Send und Receive verbunden) die genaue Wirkungsweise des IC-Send und des Receive-Moduls zu erforschen. Das erhöht das Verständnis sehr (ohne Scherz gesagt).
Wenn Du das Innere des MODULAR MINI rekonstruieren willst, dann fertige in jedem Fall zunächst eine Sicherungskopie an.
Dann verfolge zunächst im Rack jeden der Stränge; ich habe sie in der Regel kommentiert. Manche davon sind sehr einfach, zu verstehen.
Der wichtigste Analysepunkt ist der Übergabepunkt einer Ausgangsnummer über das IC-Send-Modul im Makro Ausgänge.
Ein herrliches Chaos kann man allein schon dann herstellen, wenn man ein Send-Modul (Makro Output) löscht und wieder einfügt. Dann kannst Du gleich wieder eine weitere Scherheitskopie verwenden. Die Verwaltung der Schalterpositionen der Receive-Module haben mich im Laufe des letzten Jahres schier zur Verzweiflung gebracht. Sie unterliegt ganz strengen Gestzen, die nirgendwo dokumentiert sind. Wenn ich in meine selbst erstellten Strukturen hineinschaue, muss ich mich auch wieder einlesen und erinnern. Ein anfänglich von mir geführtes Pflichtenbuch habe ich wegen Zeitmangel nur unzureichend ausgeführt.

ciao herw

 

das ist nicht genial sondern das Ergebnis der langen gedanklichen Knochenarbeit, einer gehörigen Portion Sturheit ("das muss doch möglich sein") und unendlich viel Geduld ("wann endlich kann ich mein Ensemble präsentieren?").

NI hat mit dem Multi-Display wirklich für mich das ideale Instrument herausgebracht; leider etwa fünf Monate zu spät; da hatte ich schon einige hundert Multipictures für Kabel fertig und dasselbe Konzept in R4 realsisiert. In manchen Posts habe ich in den Monaten vorher immer mal so nebenbei bei e-Mails mit Mitarbeitern von NI den Wunsch nach einer Darstellungsmöglichkeit von Kabeln erwähnt. Aber ich glaube nicht, dass das eine entsprechende Veröffentlichung des Multi-Displays forciert hat.
Was in zukünftigen REAKTOR-Versionen möglich ist, kann man immer den jetzigen anderen VSTs (wie Absynth (Display der Envelopes), Kontakt, Intakt, Guitar-Rig (Modul Tube) etc. entnehmen). Mit einiger Verzögerung werden dann diese Features auch in REAKTOR angeboten.
Ein nicht in Reaktor realisiertes Konzept ist die Skriptfähigkeit von Kontakt 2. Etwas in dieser Art wird es sicherlich auch mal in Reaktor geben. Wobei es wieder zu einem Aufschrei wie bei der Einführung der CoreCells kommt.

ciao herw

PS: eine schon historische Diskussion zu den Virtual Wires kannst Du hier nachlesen.
So waren die Anfänge in R4. Im linken Bildteil (ca. Sommer 2004) noch ohne Kabel aber schon mit Mausbedienung. Die "Kabel-Verbindung" wurde durch Text-Module angezeigt. Rechts ist schon eine spätere Version mit Multipictures in R4 zu sehen (ca. Dezember 2004).
Ernest Meyer hat mit seinem Marx Modular übrigens einen anderen Weg vollzogen.
Du kannst bei entsprechender Sucheingabe ("virtual wires", "modular", "IC-Send") viele Diskusssionsbeiträge im Forum finden.
Genial und vorbildhaft ist für mich aber immer noch der Spitzenreiter des modularen Synthsizers 3X von James Walker Hall. Natürlich könnte ich daran gehen und seinen Synthie zu einem modularen Synthsizer mit virtuellen Kabeln machen.
Aber aus Achtung vor seiner genialen Kreation, verweigere ich mich diesem "Abkupfern" und gebe mich mit meinen selbst erstellten Modulen zufrieden in der Hoffnung, auch irgendwann einmal an seine geschaffene Klangqualität heran zu kommen.