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.