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. Juce oder sonstigen Frameworks. 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.