Den Aufwand bei der Konstruktion eigener Makros darf man nicht an der Anzahl der benutzten Module messen, sondern an der Sicherheit (insbesondere der Initialisierungssicherheit) und am CPU-Verbrauch. An letzteres Kriterium komme ich nur durch Selbststudium und, wenn ich Glück habe, durch seltene Kommentare von NI-Entwicklern, die manchmal in Handbüchern, Telefonaten und eMails generelle Aussagen machen, welche Modulanordnungen man möglichst vermeiden sollte oder in geringer Stückzahl benutzen sollte.
Will man ein ganzes Geflecht von Makros erstellen, kann es auch mal zweckdienlich sein, etwas ungünstigere Strukturen zu entwickeln, damit der gedankliche Aufwand nicht Überhand nimmt.
Ich habe über meine oben beschriebene Lösung lange nachgedacht, ob ich sie so präsentieren oder eine allgemeine Lösung vorstellen sollte.
Ich habe mich dann entschlossen, die kleine Lösung vorzustellen und dort insbesondere die eher „fremden” Module zu benutzen, da man sie leicht übersieht, damit die Gedanken auch mal in andere Richtungen gehen.
Wie du sicherlich schon bemerkst, liegt der Reiz in Core unter anderem auch darin, praktische speziell an deine Vorlieben angepasste Makros zu entwickeln.
Auch der Vergleich von Lösungen zum selben Problem, wie in diesem Fall, schafft ungemein viel Erfahrung.
Das war der dritte Post über meiner Frage.... Wäre klasse wenn du den Teil mit den Modulen die man eher vermeiden sollte etwas genauer erklären kannst. Bzw. ein paar Module aufzählst.
[...]Wäre klasse wenn du den Teil mit den Modulen die man eher vermeiden sollte etwas genauer erklären kannst. Bzw. ein paar Module aufzählst.
Sehr aufschlussreicher Thread im übrigen, Danke.
generell so wenig Router wie möglich (Verwendung von logischen Masken); interessant ist hier das CoreMakro ADSR, speziell die Abfrage, welcher Synchronisationsmodus verwendet werden soll (digital-analog, legato oder nicht)
bei vielen Mehrfachverzweigungen einen Binärbaum benutzen
Audioeingänge nur, wenn wirklich audio-Signale anliegen sollen
wenig Umwandlungen von integer in float und umgekehrt (auch Konstate können sowohl integer als auch float-Darstellung annehmen)
auf die Reihenfolge von Rechenoperationen achten
statt Quadrierung lieber doppelte Multiplikation, statt Division durch Konstante Multiplikation mit dem vorher berechneten Kehrwert
Potenzen als Mehrfachmultiplikation darstellen
Ein gutes Beispiel für den letzten Punkt ist sicherlich, wenn man sich mal die Implementierung der Sinusfunktion in Core ansieht. Falls dir die Näherungsformel nicht bekannt ist, kann ich die auch hier mal posten, damit du sie in der CoreCell wiedererkennst.[/list]