Free programmable VST Instrument,Audio effect,MIDI processor/sequencer,SoundFont import,Temperaments,Multi I/O v1.0.200

[bjt2]

Current version, 1.0.174 beta:

• User manual small fixes and increased images quality.
• Bugfixes and performance enhancements.
• UI: Bugfixes and performance enhancements.
• UI: Added transparency and background image for the whole plugin editor window.
• Added options for configure the UI redraw speed.
• Added option to configure Overload/NaN protection.
• Compiled with the latest Visual Studio (2026, ver. 18.3.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.175 beta:

• Added real-time progress monitoring during project recall.
• UI embellishments: almost flicker free instrument loads/reload.
• Bugfixes.
• Compiled with the latest Visual Studio (2026, ver. 18.3.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.176 beta:

• Bugfixes and performance enhancements.
• UI: Implemented configurable rate limiters for GUI and DAW updates (see UIMOD 5).
• Compiled with the latest Visual Studio (2026, ver. 18.3.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.177 beta:

• UI: Knob skinning, even different for each Knob (see UIMOD 100+).
• Engine and UI bugfixes and performance enhancements.
• Compiled with the latest Visual Studio (2026, ver. 18.3.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.178 beta:

• UI: Introduced KNOB instruction: advanced customization of Knobs, with floating point parameters and Chromakey (transparency) on skin images.
• Engine and UI bugfixes and performance enhancements.
• Compiled with the latest Visual Studio (2026, ver. 18.4.0) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.179 beta:

• UI: Introduced Double Buffering and bitmap caching for flicker free UI even on older systems.
• UI bugfixes and performance enhancements.
• Compiled with the latest Visual Studio (2026, ver. 18.4.1) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.180 beta:

• Bugfix POST step.
• Added option to KNOB instruction.
• Added Temperament blend feature.
• Compiled with the latest Visual Studio (2026, ver. 18.4.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.181 beta:

• Added more predefined temperaments.
• Added secondary temperament option for temperament blend.
• Compiled with the latest Visual Studio (2026, ver. 18.4.2) and SDK (10.0.26100.7705).

[bjt2]

Current version, 1.0.182 beta:

• Added 32 bit version.
• Compiled with the latest Visual Studio (2026, ver. 18.4.3) and SDK (10.0.26100.7705).

[Frank_Kreuzberg-Audio]

This looks like a really powerful tool, a proper DSP playground. I'm particularly interested in the PREV instruction for implementing feedback systems. How do you handle topologies where the feedback path needs to be resolved within the same sample? For instance, in state variable filters or circuit modeled structures, you often need to solve a system of equations to avoid the inherent one sample delay of a simple z-1 block. Does the language allow for some form of iterative solving or does it rely on users reformulating their algorithms into a structure like Direct Form? Really impressive project, great to see this kind of creative freedom.

Frank

[bjt2]

This looks like a really powerful tool, a proper DSP playground. I'm particularly interested in the PREV instruction for implementing feedback systems. How do you handle topologies where the feedback path needs to be resolved within the same sample? For instance, in state variable filters or circuit modeled structures, you often need to solve a system of equations to avoid the inherent one sample delay of a simple z-1 block. Does the language allow for some form of iterative solving or does it rely on users reformulating their algorithms into a structure like Direct Form? Really impressive project, great to see this kind of creative freedom.

Frank

The prev instruction just accesses the result slot pertaining to that variable. If you access the slot before the first assignment that pertain to that variable, you just take the value of the variable at the preceding sample. It's simply a shortcut to a thing that in a normal programming language is forbidden: accessing an undefined value. But since all the slots are initialized to zero and the calculations are multiple and sequential, you just have the previous sample value... This is also the reason you need a dummy variable to use a keyword: the keywords are implicitly defined each sample before the process starting. There is no other way to access previous sample of a keyword. PREV(KEYWORD) will always obtain the current value.

There is somewhere in the PDF an example of FM modulation with self-modulating oscillators (using PREV) and the explanation of the EKS algorithm. The EKS specifically leverages the feedback delay lines (DELAYF) to implement its physical modeling structure. The EKS example is included in the package (Waveguide.txt) and you can have fun playing with it, modify it etc... The FM example is briefly mentioned in the PDF and there is a sample file (Feedback test.txt). Both those examples show the engine handles different feedback topologies, from unit delays to longer lines.

Regarding your question on ZDF and resolving equations within the same sample: currently, the engine follows a sequential execution model where PREV inherently introduces a 1-sample delay (z^-1). While the language doesn't natively support implicit iterative solvers (like Newton-Raphson) to resolve delay-free loops, it provides the creative freedom to implement TPT (Topology Preserving Transform) structures. You can algebraically solve the loop 'on paper' and then code the resulting filter coefficients and state updates directly in the script. It’s a more 'manual' approach but keeps the CPU overhead predictable and ensures the rock-solid stability I aimed for.

If you want to go deeper, you can manually manage delay lines for more complex topologies. I kept the engine as transparent as possible: no hidden compensations, just raw DSP power. If you can solve the math, Crescendo can run it.


To give you some background on the philosophy behind Crescendo: as an engineer who spent a lot of time with MATLAB and Simulink during my university years, I wanted to bring that same 'system-oriented' approach to the VST world.

Furthermore, my current professional background as a researcher in the medical field significantly influenced the engine's development. I spent years developing image processing software and working with C++, Matlab, CUDA, Fortran and IDL for scientific analysis.

I envisioned Crescendo as a Simulink-like environment for audio. This is why the architecture is fundamentally MIMO (Multiple Input, Multiple Output). It doesn't just process a stereo stream; it’s designed to handle complex routing where multiple internal layers and external inputs can interact dynamically. Whether you are building a MIDI processor, a polyphonic synth, or a multi-stage effect rack, the goal was to provide a transparent DSP canvas where the user is the system architect.


To give you a concrete idea of how the PREV logic works for classical DSP structures, here is a snippet from the manual showing a generic IIR Filter implementation. It highlights how you can manually manage the state variables:

Code: Select all

// Example: Generic IIR Filter structure
XNM = PREV (XNM1)
...
XN2 = PREV (XN1)
XN1 = PREV (INPUT)
INPUT = ... // input signal

YNM = PREV (YNM1)
...
YN2 = PREV (YN1)
YN1 = PREV (Y)

// Core IIR equation: for a FIR filter, YNs are not needed.
Y = ... // any expressions involving INPUT, XNs and YNs 

OUT = Y
// NOTE: the order of the assignments is fundamental.

This level of transparency is what I aimed for: a tool where you can translate an algorithm from a textbook or MATLAB script directly into a working VST with minimal friction.

[xhunaudio]

Have you ever tought to a "VST plugin export" function for Crescendo, on the long run? (Just an idea...)

Congrats and keep up your great work.

[bjt2]

Have you ever tought to a "VST plugin export" function for Crescendo, on the long run? (Just an idea...)

Congrats and keep up your great work.

Thanks for your interest!
If i get what you mean... in a sense, yes, and it is already possible. Just put all the code in the settings.ini. But i should add an instruction to hide the load buttons and this means that there can be only one crescendo identity.

Better would be the next idea: If the DLL is renamed (e.g., CustomSynth.dll), the engine will:
Automatically look for a matching CustomSynth.txt script.
Engage a "Player Mode" (Hard-locking the UI, hiding dev-tools/logs).
Override VST metadata (Vendor/Version) to reflect the custom instrument's branding.
I must define naming conventions for effect/synth on DAWs that require this (Audacity, Ableton)
I must add instructions for branding...

This should not be too hard to implement.

I have already some support code in place: currently the engine uses a single binary core that adapts its VST identity during the initialization phase, using getmodulename(). By retrieving its own filename, the DLL determines what parameter pass to isSynth and the initial I/O bus configuration. This ensures "hard" compatibility with DAWs like Ableton or Audacity by providing dedicated versions (Crescendo.dll, -effect.dll, -MIDI.dll) that are byte-for-byte identical but functionally specialized.

[xhunaudio]

At first (just as a "compulsive" idea) I meant a standard, embedded micro-compiler inside Crescendo, for compiling standalone plugins out of Crescendo projects...

But your idea seems even better ! Basically, a standard Crescendo plugin renamed and "hardwired" to a specific Crescendo project, with locked GUI, etc.

I don't know if it's possible to instantiate (at run time) the plugin parameters *names* (the ones visible from/to the DAW) according to the parameters names indicated in the a Crescendo project / script to be loaded.

Also, if there's a way to obfuscate/hide the original project code text/content, Crescendo could reach (in the future) the commercial development scenario, in addition to the prototyping step. The same exact script/code running on SSE, AVX2, AVX10.2 or 32-bit (according to the .dll you choose to load) would be a step into the future of development. A good starting point concept could be CMajor (also with a different syntax).

Just a bounch of considerations on my side, eheh - on the long run. Again keep up you great work !

[bjt2]

At first (just as a "compulsive" idea) I meant a standard, embedded micro-compiler inside Crescendo, for compiling standalone plugins out of Crescendo projects...

But your idea seems even better ! Basically, a standard Crescendo plugin renamed and "hardwired" to a specific Crescendo project, with locked GUI, etc.

I don't know if it's possible to instantiate (at run time) the plugin parameters *names* (the ones visible from/to the DAW) according to the parameters names indicated in the a Crescendo project / script to be loaded.

Also, if there's a way to obfuscate/hide the original project code text/content, Crescendo could reach (in the future) the commercial development scenario, in addition to the prototyping step. The same exact script/code running on SSE, AVX2, AVX10.2 or 32-bit (according to the .dll you choose to load) would be a step into the future of development. A good starting point concept could be CMajor (also with a different syntax).

Just a bounch of considerations on my side, eheh - on the long run. Again keep up you great work !

Thanks for your appreciation!

My engine translates the text file into an array of ops (even filtered conditionally at trigger time if prefixed with EXECIF) that are then processed in a loop. Generating an executable it's out of my capabilities...

The parameter names and units are requested by the DAW at runtime: the same dll can change depending to whatever script you load. The only culprit is that some DAWs cache the number of parameters.

The obfuscation can be a requirement for truly commercial software. I can think of an embeeding of the text in a resource of the DLL and then a developer can use a resource editor? I must think if it is feasible.