Interessiert an einem Austausch zum Thema DSP-Entwicklung?

[_thomas_]

Was ich in diesem Forum bisher vermisse (oder noch nicht gefunden habe) ist ein Thread, in dem sich mit der Entwicklung von DSP-Komponenten befasst wird. Damit meine ich: komplett selbst gebaut und nicht die Nutzung von z. B. MAx/Pure Data oder sonstiger Umgebungen. Und auch nicht nur theoretisch, sondern ganz konkret umgesetzt (in welcher Sprache auch immer). Ich persönlich nutze C++. Pure Data dient mir als Audio-Host und UI.

Ich vermute aber, dass das in der Form nur sehr wenige Menschen so unterwegs sind. Lasst trotzdem gern mal oben in der Umfrage eure Stimme da.

 

[_thomas_]

Aktuelles Projekt für die Weihnachtsferien ist übrigens ein Granular-System (läuft schon ganz gut):

Ich hänge alle Objekte in eine hierarchische Struktur. Das bietet einiges an Möglichkeiten, auch bei der Fehlersuche.

 

[einseinsnull]

DSP ist DSP. Der/die/das DSP ist nicht an eine Sprache gebunden, auf die Verfahren selbst kommt es an.
Mit Ausnahme von custom RAM access funktioniert das in Max/SC/Flowstone/Hastenichgesehen nicht anders als OOL/Hochsprachen auch.

Will sagen: DSP interessiert mich - C++ nicht (Dafür hab ich Sklaven). :)

 

[Dagalos]

Ich fände das interessant, kann aber nicht so viel beisteuern, habe mal einen kleinen Synth in C++ mit Qt als GUI geschrieben, ist aber auch schon Jahre her und besonders toll klang der auch nicht, wollte sowas halt mal probieren. Seit der Zeit habe ich großen Respekt vor Plugin Entwicklern, die großartigen Sound damit hinbekommen.

 

[Klinke]

Ich programmiere zwar gerne Tools zum Musik machen (Sequenzer, Looper und Mackie Control für Reaper), aber meine DSP Erfahrung begrenzt sich vor allem auf PureData und ein wenig SuperCollider, direkt in C++ habe ich noch kein DSP Code geschrieben. Würde mich schon interessieren, aber dafür fehlt halt einfach die Zeit.

 

[DanReed]

Der/die/das DSP ist nicht an eine Sprache gebunden,

Theoretisch nicht, praktisch sehr wohl, denn ob Du ein Verfahren/Alg in matlab oder C oder Lisp oder Modellsprache oder mathematisch formulierst, ist für den Aufwand einer eigenen Implementation oder Analyse von (meiner Meinung nach) großer Bedeutung.

 

[_thomas_]

DSP ist DSP

Sicher, hier geht's halt um die Herangehensweise.

unktioniert das in Max/SC/Flowstone/Hastenichgesehen nicht anders als OOL/Hochsprachen auch

Ha ha... Nein, das sehe ich ganz anders. Nämlich genau so:

ob Du ein Verfahren/Alg in matlab oder C oder Lisp oder Modellsprache oder mathematisch formulierst,ist für den Aufwand einer eigenen Implementation oder Analyse von (meiner Meinung nach) großer Bedeutung.

Na ja. Schwieriges Thema. Ich kann schon verstehen, dass das so einige echt interessiert. Aber Zeit ist knapp und die Interessen sind zahlreich. Und Lowlevel was auf die Beine zu stellen, ist erstmal recht aufwändig. Ich dachte, ich frag mal...

 

[DanReed]

DSP ist eins einer Lieblingsthemen. Also: Nur zu.

Ich halte matlab/scilab/octave für eine gute Lösung, um Verfahren in gewissen Grenzen theoretisch zu erfassen und gleichzeitig auch praktisch zu testen. Viel einfacher, als erst eine jeweils passende Umgebung zu erzeugen.

 

[amesser]

Aktuelles Projekt für die Weihnachtsferien

Hmm, da kann jemand wohl doch nicht die Finger vom Compiler lassen Schönen Gruß und schon mal guten Rutsch! Können wir auch FPGA Algorithmen mit aufnehmen ? Irgendwann brauch ich auch noch Effekte und Filter...

 

[DeepSea]

Mich interessiert das Thema ebenfalls, hauptsächlich auf die Programmierung von Microcontrollern bezogen. Meine Erfahrung beschränkt sich bisher auf C++ und Arduino IDE.

Ich denke allerdings, man wird wohl für die verschiedenen Sprachen auch eigene Threads brauchen. Andernfalls stelle ich es mir schwierig vor, ein Durcheinander zu vermeiden.

 

[_thomas_]

Können wir auch FPGA Algorithmen mit aufnehmen

Zufällig kenne ich jemanden (Synthie-Stammtisch Rodgau, auch hier im Forum), der sich damit auskennt. Juckt durchaus schon etwas in den Fingern...

 

[rolfdegen]

DSP mit grafischer Programmierumgebung wzB beim FV-1 wäre super. Dann brauch man sich nicht mit der programmierung rumschalgen.



Ich arbeite zur Zeit noch mit Teensy und programmiere aufwendig in C. Da dauert eine Entwicklung schon etwas länger.

 

[_thomas_]

DSP mit grafischer Programmierumgebung wzB beim FV-1 wäre super

Schon, aber was machst du da bei "Spezialanforderungen?

Nur mal so als Beispiel: Ich bin gerade dabei eine "Swarm"-Funktion in meinen Granulator einzubauen. Der Schwarm (wie die Sperlinge) soll sich im Stereofeld bewegen. Und wie die Sperlinge aber sollen die Grains unterschiedliche Geschwindigkeiten haben, um eben diesen Schwarm mit seinen unterschiedlichen Dichten zu simulieren. Und dieser Punkt soll halt nicht mit linearer Geschwindigkeit durchs Feld bewegt werden, sondern in Abhängigkeit zur Zeit auch noch variieren. Das verwirkliche ich, indem ich mit S-Kurven arbeite.

Wie mache ich das? Nehme ich Perlin-Noise oder baue ich mir einen Random-Walk um (smooth) einen virtuellen sich bewegenden Punkt zu erzeugen, zu dem die Sperlinge dann streben?

Entschieden habe ich mich für den Random-Walk (aktueller Arbeitsstand):

#include "RandomWalk.h"

void RandomWalk::initializeModulationProcessor(size_t)
{
    currentTarget = previousTarget = 0.0f;
    currentSample = 0;

    time.initialize(
        "time", this, 10.0f, SIGNAL_MAX, 500.0f,
        [this](const signal &t)
        {
            currentTime = t;
            totalSamples = currentTime * DSP::SAMPLERATE_MS;
            return t;
        });

    curve.initialize(
        "curve", this, -1.0f, 1.0f, 0.5f,
        [this](const signal &c)
        {
            currentCurve = c;
            return c;
        });

    unipolar.initialize(
        "unipolar", this, false,
        [this](const bool &u)
        {
            currentUnipolar = u;
            return u;
        });

    curveRandomization.initialize(
        "curveRandomization", this, 0.0f, 1.0f, 0.0f,
        [this](const signal &r)
        {
            currentCurveRandomization = r;
            return r;
        });
}

void RandomWalk::processModulationBlock()
{
    for (size_t i = 0; i < DSP::BLOCKSIZE; ++i)
    {
        if (currentSample >= totalSamples)
        {
            previousTarget = currentTarget;
            currentTarget = currentUnipolar ? random.nextUnipolar() : random.nextMRS();
            totalSamples = currentTime * DSP::SAMPLERATE_MS;
            currentSample = 0;

            if (previousTarget < currentTarget)
                currentCurveExponent = dsp_math::shape_to_exponent(currentCurve * -1.0f);
            else
                currentCurveExponent = dsp_math::shape_to_exponent(currentCurve);
        }

        phase = static_cast<signal>(currentSample) / static_cast<signal>(totalSamples);
        outputBus.m[i] = dsp_math::power_lerp(previousTarget, currentTarget, phase, currentCurveExponent) * m_depth.values[i] + m_offset.values[i];

        currentSample++;
    }
}

Was ist hier der Unterschied zu Max/etc.? Ich habe wirklich jede Freiheit und muss nicht rumhampeln. Einen Random-Walk mit S-Kurven möchte ich in PD z. B. nicht bauen. Und in Max wahrschienlich auch nicht.

Ob sich die Mühe lohnt, kann ich natürlich erst sagen, wenn ich das Ergebnis gehört habe. Aber wenn es nichts sein sollte, habe ich hier a) eine schöne neue und wiederverwendbare Komponente und b) nicht so abartig viel Zeit verbrannt. Das sind schließlich nur ein paar Codezeilen. Wenn man mal die "Infrastruktur-Hürde" genommen hat, ist das alles nämlich überhaupt nicht mehr aufwändig.

 

[_thomas_]

Arduino IDE

Ich entwickle hauptsächlich für den Raspi. Wir schauen einfach mal, wie das hier so läuft.

Ich halte matlab/scilab/octave für eine gute Lösung

Da fehlen mir gerade die Use-Cases. Hast du mal ein Beispiel? Prinzipiell fände ich es auch wünschenswert wenn ich ein Tool hätte, mit dem ich für irgendwelche Ideen abschätzen könnte, ob sich das überhaupt lohnt. Siehe Schwarm-Funktion.

 

[_thomas_]

Noch ein kleiner Nachtrag zu meinem Random-Walk: da diese Parameter in "initializeModulationProcessor" sich alle modulieren ließen (Feature der Parameter: man kann einen LFO oder eine Hüllkurve dran hängen), könnte ich sogar eine sich bewegende S-Kurve abbilden. Aber ich denke, dass das fürs Stereofeld nix bringt.

 

[einseinsnull]

Theoretisch nicht, praktisch sehr wohl, denn ob Du ein Verfahren/Alg in matlab oder C oder Lisp oder Modellsprache oder mathematisch formulierst, ist für den Aufwand einer eigenen Implementation oder Analyse von (meiner Meinung nach) großer Bedeutung.

Vieles daran ist ganz anders zu machen, aber der Kern der Sache ist doch mehr oder weniger überall der Gleiche. In Max muss ich auch ein und den selben code von MAX nach MSP nach jit.expr nach gen~ nach RNBO übersetzen und überall läuft das Hasilein wieder ein bischen anders, trotzdem ist es eigentlich der immer gleiche Prozess wenn man irgendeinen Generator oder Effekt machen will.

Du brauchst einen Biquad für data Rate? Kein Problem, bau dir einen, der genauso funktioniert wie der, den Du für signal rate bereits hast, dann kannst Du ihn auch ohne groß nachzudenken genauso benutzen.

Du musst ja nicht einen Delay Effekt in max oversamplen und in java plötzlich nicht und in flowstone geht es nur wenn ein game console treiber geladen ist oder sowas - Das Verfahren ist immer gleich.

Die Nicht-Hochsprachen/Nicht-Assembler haben nur einfach ein paar kleine Sachen, die man dort nicht so ohne weiteres selbst machen kann und im Falle von Max und CSound ist da auch ein bischen zuviel Fertigfutter dabei für meinen Geschmack (eine bereits existierende Raumhall Klasse in Max oder den mitgelieferten Moog Filter bei JUCE zu benutzen fühlt sich nicht mehr wirklich wie "selbst machen" an :) )

Für mich als jemand, der mathematikwissenschaftliche Notation und Erklärungen oft nicht lesen und verstehen kann (und daher schon mit matlab, dspreleated oder stackexchange Probleme hat) sind andere User aus der eher kreativen Ecke (oder ein KI chatbot) relativ wichtig zum Austausch, ich brauche das alles metaphorisch bzw. in linearem pseudo code.

DSP mit grafischer Programmierumgebung wzB beim FV-1 wäre super. Dann brauch man sich nicht mit der programmierung rumschalgen.

Anhang anzeigen 273777

Also ich habe nicht mal einen Schulabschluss und mir ist eine Umgebung, in der ich selbst entscheiden kann welche Auflösung und welches Zahlensystem ein Poti GUI hat und wie ich das dann mit einer 30 Centimer langen expr gleichzeitig verzerren, skalieren und auf 2 empfänger aufteilen kann immer noch lieber wie so ein Baukasten, bei dem selbst "*" plötzlich "Volume" heißt, obwohl man genauso gut noch was anderes damit multiplizieren könnte wie eine Musiksignal-Amplitude.

Es muss ja nicht gleich C++ sein.

Das ist so ein bischen, was ich oben zu thomas sagte; Das schöne an expr, den Grundrechenarten, pow, Trigonometrie und Logik ist ja, dass das Zeug erst mal in allen Sprachen gleich ist.
Bei FFT sitzt man dann natürlich mit max und pure data in einem goldenen Käfig, aber + und - sind universell, und somit lässt sich vieles einfach in deutsch oder englisch erklären und sich darüber austauschen.

Wenn ich Dich jetzt frage, welches Signal bei bei linearer FM wie skalieren muss, könntest Du mir das nur in C++ "beantworten"? Falls ja, dann hättest Du es nicht vollumfänglich verstanden und Deine Antwort würde jemanden, der etwas anderes benutzt ggf. nicht helfen. Das muss also auch mit Sprache möglich sein.
Außer Du bis Mathematikprofessor. Dann liegt es in meinem Fall am Empfänger, dass nicht mehr alles ankommen wird, egal wie generisch es präsentiert wird.

 

[einseinsnull]

Schon, aber was machst du da bei "Spezialanforderungen?

Nur mal so als Beispiel: Ich bin gerade dabei eine "Swarm"-Funktion in meinen Granulator einzubauen. Der Schwarm (wie die Sperlinge) soll sich im Stereofeld bewegen. Und wie die Sperlinge aber sollen die Grains unterschiedliche Geschwindigkeiten haben, um eben diesen Schwarm mit seinen unterschiedlichen Dichten zu simulieren. Und dieser Punkt soll halt nicht mit linearer Geschwindigkeit durchs Feld bewegt werden, sondern in Abhängigkeit zur Zeit auch noch variieren. Das verwirkliche ich, indem ich mit S-Kurven arbeite.

Wie mache ich das? Nehme ich Perlin-Noise oder baue ich mir einen Random-Walk um (smooth) einen virtuellen sich bewegenden Punkt zu erzeugen, zu dem die Sperlinge dann streben?

Entschieden habe ich mich für den Random-Walk (aktueller Arbeitsstand):

#include "RandomWalk.h"

void RandomWalk::initializeModulationProcessor(size_t)
{
    currentTarget = previousTarget = 0.0f;
    currentSample = 0;

    time.initialize(
        "time", this, 10.0f, SIGNAL_MAX, 500.0f,
        [this](const signal &t)
        {
            currentTime = t;
            totalSamples = currentTime * DSP::SAMPLERATE_MS;
            return t;
        });

    curve.initialize(
        "curve", this, -1.0f, 1.0f, 0.5f,
        [this](const signal &c)
        {
            currentCurve = c;
            return c;
        });

    unipolar.initialize(
        "unipolar", this, false,
        [this](const bool &u)
        {
            currentUnipolar = u;
            return u;
        });

    curveRandomization.initialize(
        "curveRandomization", this, 0.0f, 1.0f, 0.0f,
        [this](const signal &r)
        {
            currentCurveRandomization = r;
            return r;
        });
}

void RandomWalk::processModulationBlock()
{
    for (size_t i = 0; i < DSP::BLOCKSIZE; ++i)
    {
        if (currentSample >= totalSamples)
        {
            previousTarget = currentTarget;
            currentTarget = currentUnipolar ? random.nextUnipolar() : random.nextMRS();
            totalSamples = currentTime * DSP::SAMPLERATE_MS;
            currentSample = 0;

            if (previousTarget < currentTarget)
                currentCurveExponent = dsp_math::shape_to_exponent(currentCurve * -1.0f);
            else
                currentCurveExponent = dsp_math::shape_to_exponent(currentCurve);
        }

        phase = static_cast<signal>(currentSample) / static_cast<signal>(totalSamples);
        outputBus.m[i] = dsp_math::power_lerp(previousTarget, currentTarget, phase, currentCurveExponent) * m_depth.values[i] + m_offset.values[i];

        currentSample++;
    }
}

Was ist hier der Unterschied zu Max/etc.?

ich sehe ihn erst mal nicht, da Du perlin.h aufrufst und das nichts anderes wie ein objekt in pure data aufzurufen. falls es dort weniger Parameter hat, ist es halt schlecht gemacht, das liegt dann aber nicht an der Umgebung und kann einem selbst ja auch passieren.

Die eigentlich interne perlin interpolation ist immer gleich, und ob man die nun selbst (ab)schreibt oder nur weiß, was eine Klasse macht, wo ist der Unterschied.

Und genexpr/gen~ codebox in Max ist syntaktisch und grammatisch schon recht dicht an C++, kannst Du eines davon halbwegs und das andere nicht oder kaum, kannst Du den Code trotzdem problemlos "übersetzen".

in pd hast Du für deine Sperlinge pmpd-3D, damit beeinflussen die sich dann alle gegenseitig, aber das weißt du selbst.

Ich habe wirklich jede Freiheit und muss nicht rumhampeln. Einen Random-Walk mit S-Kurven möchte ich in PD z. B. nicht bauen. Und in Max wahrschienlich auch nicht.

Ob sich die Mühe lohnt, kann ich natürlich erst sagen, wenn ich das Ergebnis gehört habe.

Du musst erst hören, was eine mathematische Formel machen soll? Ich dachte man entscheidet sich immer für die, die man braucht um ein bestimmtes Ergebnis zu erreichen. :)

 

[einseinsnull]

Können wir auch FPGA Algorithmen mit aufnehmen ?

Wenn Du erklärst, was das überhaupt sein soll, ist da sicher noch viel Platz dafür.

Mit was fangen wir an, mit Atari? ;)

 

[Dagalos]

Ich fände es gut wenn wir über Algorithmen in der Hauptsache reden, optimal mit einer Minimalimplementierung in C oder zur Not auch Pseudocode. Mit grafischer Programmierung habe ich persönlich keine Erfahrung.
Ich beginne auch wirklich gern von Null. Bei meinem kleinen Synth hatte ich den Audiobuffer und das wars, dann lag es an mir den zu füllen. Da ich keine große Ahnung von DSP habe, hatte ich das Buch "Designing Software Synthesizer Plugins in C++" als Leitpfaden genommen, aber da auch nur die Kernsachen. Bei Geschichten wie Mehrstimmigkeit habe ich erstmal gerudert, da ich die ganzen Sachen mit Noten klauen etc. erstmal gedanklich begreifen musste oder dass es meist nix bringt einen Knob einfach 1:1 die Werte zu übertragen usw.
Gut von den Filtern hatte ich gar keine Ahnung und die auch nur abgeschrieben. Ich habe auch versucht sowas ZDF Filter zu begreifen, das hat nur so halb geklappt.

Was mich noch interessieren würde wäre die Simulation von Elektronischen Schaltungen, was ja ein komplett anderer Ansatz ist wie die klassische Softsynth Programmierung.

Was ich auch nicht gemacht hatte war ein Plugin zu programmieren. Mein Synth war eine eigene Anwendung mit Qt als GUI. Die Lib Portaudio hatte ich benutzt um einen Audiobuffer zu bekommen.

Hauptproblem ist bei mir auch die Zeit, die ist eher wenig vorhanden und wenn dann möchte ich auch noch ein wenig Musik machen bzw. rumklimpern.

Hier mal der Link zu dem Buch was mir geholfen hatte. Heute würde man wohl eher die KI fragen.
https://www.amazon.de/dp/0367510464?ref=cm_sw_r_ffobk_cp_ud_dp_HY1BJS26YQ2HWXSRCY57&ref_=cm_sw_r_ffobk_cp_ud_dp_HY1BJS26YQ2HWXSRCY57&social_share=cm_sw_r_ffobk_cp_ud_dp_HY1BJS26YQ2HWXSRCY57&bestFormat=true

 

[einseinsnull]

Bei Geschichten wie Mehrstimmigkeit habe ich erstmal gerudert, da ich die ganzen Sachen mit Noten klauen etc. erstmal gedanklich begreifen musste

Logik ist manchmal schwieriger als Audio! Mach Dir keine Sorgen deswegen, Du bist ganz gesund. :)

MIDI, Logik, GUI, Frameworks, Laufzeitumgebung, Threading und Deployment sind aber alles diese Themen, die zwar drumherum zwingend stattfinden, aber eigentlich nicht Teil der "Signalbearbeitung" sind.

 

[AlexDozer]

Ich bastel mir gerade auch ein Effekt-Gerät. Benutze dafür einen Daisy Seed. Das ganze soll später auch gekoppelt werden mit einem STM32H7 um Daten auf einem Display anzuzeigen.
Ich stehe aber noch relativ am Anfang. Das ist mein erster Berührungspunkt mit Mikrocontrollern. Und in C++ habe ich auch schon ewig nichts mehr gemacht. Wird also noch ein bisschen dauern
bis mein Projekt fertig ist. Aber es geht vorwärts.

 

[_thomas_]

ich sehe ihn erst mal nicht, da Du perlin.h aufrufst und das nichts anderes wie ein objekt in pure data aufzurufen

Warum auch? Ich habe mich aus Gründen der Laufzeit-Effizienz bei dem Problem eben für den Random-Walk entschieden, weil es für das Problem vollkommen ausreichend ist, aber wesentlich weniger CPU-Ressourcen benötigt. Hatte ich so ähnlich geschrieben. Musst du dann auch lesen. Und das genau ist der Unterschied: ich gestalte und baue das Pure-Data-Objekt selbst. Das andere ist die Anwendung. Da musst du mit dem klar kommen, was dir die Komponente anbietet. Vielleicht können wir diese Grundsatzdiskussion hiermit beenden? Mir geht's um Low-Level-Entwicklung, um Theorie und Umsetzung um es dann anwenden zu können. Du bist einen Schritt weiter in der Anwendung, die natürlich theoretische Kenntnisse einschließt. Es ginge auch noch eine Stufe weiter runter. Das macht @amesser gerade mit seinem FPGA-Projekt. Technologisch superspannend, aber ich möchte meinen Granulator dann doch relativ zügig umgesetzt bekommen.

Bei meinem kleinen Synth hatte ich den Audiobuffer und das wars, dann lag es an mir den zu füllen.

Schon krass, was man alles machen muss um, einen Puffer mit sinnvollen Werten zu befüllen. Was diese(n) Puffer angeht, habe ich ein Bussystem für Audio (grundsätzlich Stereo) und Modulation entwickelt. Da hängt man die DSP-Objekte einfach an der richtigen Stelle rein, oder koppelt sie bei Bedarf einfach wieder ab. Wie die Verbinder in Max.

Beispiel:

wetBus = BusManager::registerAudioBus(wetBusName, this);
dryBus = BusManager::registerAudioBus(voicesOutputBusName, this);
modFilterCutoffBus = BusManager::registerModulationBus(modFilterCutoffBusName, this);

# Beispiel
lfo1.connectOutputToBus(modFilterCutoffBus);
lowpassCutoff.connectOutputToBus(modFilterCutoffBus);

# oder
delay.connectInputToBus(wetBus);

# Oder ein Dry/Wet Mixer der direkt auf dem Puffer des Hosts sitzt
drywetFader.connectInputAToBus(dryBus);  // input A dry
drywetFader.connectInputBToBus(wetBus);  // input B wet
drywetFader.connectOutputToBus(hostBus); // Host output

Und das läuft superstabil. Es sei denn, man hat vergessen, ein Objekt mit einem Bus zu verbinden. Dann knallt es natürlich. Und wenn es knallt, dann weiß man auch sofort, dass man vergessen hat das Ding an den Bus zu hängen.

Wie gesagt: hat man die Infrastruktur im Griff, kann man sich voll auf die Umsetzung konkreter Bedürfnisse konzentrieren. Und mit jedem Projekt wächst die Funktionalität.

Ich fände es gut wenn wir über Algorithmen in der Hauptsache reden

Ja, warum nicht? Die Umsetzung ist aber bestimmt auch spannend. Aber man muss ja nicht alles allein machen.

Was ich auch nicht gemacht hatte war ein Plugin zu programmieren.

Das ist natürlich essentiell um es integrieren zu können. Ich selbst nutze gerade auch erstmal nur PD, da das Plugin-Format supersimpel aufgebaut ist und PD auch auf Linux/ARM (Raspi) läuft. Aber mittelfristig will ich die Komponenten auch in der DAW nutzen können. Da wird es bei mir wohl auf LV2 hinauslaufen. Das ist auch relativ einfach umzusetzen und hat breite Unterstützung (außer auf Windows, glaube ich).

 

[2bit]

Will sagen: DSP interessiert mich - C++ nicht (Dafür hab ich Sklaven). :)

Dann bist du hier wohl falsch. Es wäre wirklich cool, wenn du den Thread nicht mit ausufernden Grundsatzdiskussionen kapern und zerlabern würdest. Mich interessiert nämlich ein agnostischer Ansatz ohne irgendwelche proprietären Software-Vehikel oder UI-Node-Sackgassen viel mehr. DSP ist nämlich nicht nur im Audiobereich ein Ding.

 

[Turing]

Es wundert mich, dass Du JUCE-Nutzer kategorisch ausnimmst.
Auch bei Verwendung von JUCE wird man alles komplett selbst programmieren, was irgendwie "interessant" ist.

 

[_thomas_]

Es wundert mich, dass Du JUCE-Nutzer kategorisch ausnimmst.

Sorry, ich kenne Juce nicht wirklich und hab da vielleicht Vorurteile. Wenn du was Cooles in Juce machst, bist du hier auf jeden Fall auch willkommen.

Den Startbeitrag habe ich entsprechend angepasst. Danke für den Hinweis!

 

[2bit]

Damit man auch nicht sämtliche Räder neu erfinden muss, weise ich mal auf airwindows hin, bzw. das dazu gehörende quelloffene git-Repository, wo man wirklich tonnenweise Algorithmen finden kann. Alles natürlich in cpp geschrieben und für mac, linux und windows veröffentlicht. Ohne Juce. Mehrere dutzend kleine Audio-Plugins ohne nennenswerte UI-Krücken, die funktional immer nur eine einzige Kernaufgabe erledigen und somit wenige Parameter erfordern, dürften den Fokus dieses Themas gut treffen.

 

[einseinsnull]

Dann bist du hier wohl falsch. Es wäre wirklich cool, wenn du den Thread nicht mit ausufernden Grundsatzdiskussionen kapern und zerlabern würdest. Mich interessiert nämlich ein agnostischer Ansatz ohne irgendwelche proprietären Software-Vehikel oder UI-Node-Sackgassen viel mehr. DSP ist nämlich nicht nur im Audiobereich ein Ding.

Für allgemeine C++ Programmierung gibt es Foren mit 100,000 aktiven Mitgliedern.

So wie es aussieht ist hier C++ im Moment eher die Minderheit, und dass es hier um Audio Signale gehen sollte und nicht um Radar oder Luftdruck dürfte keiner Grundsatzdiskussionen bedürfen.

Außerdem ist Juce ein C++ Framework, in Max gibt es immerhin ähnliches, CSound gibt es für C++, die Supercollider source ist ebenfalls größtenteils C++... und das Zeug sicherlich viel rudimentärer als irgendwelche plug-ins.

Alles natürlich in cpp geschrieben und für mac, linux und windows veröffentlicht. Ohne Juce

Ursprünglich, ja. Aber die Nutzer benutzen meisten JUCE, z.b. für das "consolidated", er selbst auch zunehmend, sobald etwas ein GUI braucht. :)
Nicht, dass ich Fan davon wäre, aber die Leute sind ja nicht alle doof und das hier als "Gegenteil" von C++ Entwicklung hinzustellen finde ich sehr kreativ.

 

[2bit]

@einseinsnull Was du hier veranstaltest ist ermüdend und laugt aus. Wirklich. Du willst nicht das selbe, wie der TE.

 

[_thomas_]

Nicht, dass ich Fan davon wäre, aber die Leute sind ja nicht alle doof und das hier als "Gegenteil" von C++ Entwicklung hinzustellen finde ich sehr kreativ.

Sorry, da habe ich mich vielleicht etwas unklug ausgedrückt, mag sein. Genau diese Absicht aber hat hier ganz sicher niemand. Ich auch nicht. Aber vielleicht können wir es dabei jetzt belassen?