Port DSP to JUCE

[dozius]

Goals

• Port all sound processing code to the JUCE project
• Ensure processing is fully functional within the new framework

[PaulHaeger]

This will probably take some time.

My rough personal road map would be this:

• Get Familiar with JUCE
• Get Familiar with the DtBlkFx code
• Port the code

I would create a simplistic test GUI alongside that would get replaced with a proper one later.

Am I missing something here or does this sound okay ?

[dozius]

Yes, this is where the heavy lifting starts.

Sounds like a reasonable plan. The only other consideration I can think of would be modernizing and refactoring, but maybe that could be a part of a second pass after things have been ported.

You probably don't need to worry about a GUI at all at this point. Publishing the parameters is enough for a DAW to see the parameters and interact with them. I've taken this approach in the past and it works well for developing the processing end of things.

[PaulHaeger]

If I see something that could be obviously refactored I see no problem in doing that.

But yeah, a general refactor would probably be better for a second pass.

[PaulHaeger]

A short status update since it has been quite long since the last message.

I decided open up a second branch and do a second port attempt. The first time I made the mistake of trying to refactor things directly in the beginning. This way I programmed myself into a corner and progress became very slow. To that school also has been taking some of my energy.

With the second attempt my initial goal is to leave as much unchanged as I can until I have a version that is running in JUCE. After that I can worry refactoring stuff. With this approach I hopefully wont put myself into a corner again.

[danielmkarlsson]

Hello.
I would like to just state I am using dtbklfx on a daily basis and that it is very dear to me. Nothing else that I am aware of sounds even remotely close. I've been making a bunch of music with it and some of it can be heard here:

https://danielmkarlsson.com/ruins-in-the-distance/

I am really rooting for y'all and I really hope that everything works out with this amazing piece of software so that future generations of composers of weird music can get to experience it.

[PaulHaeger]

A status update on the current progress:

Recently I found some time to get a good amount of stuff done. It seems like everything compiles now.
The next step is to connect the parameters to JUCE and expose them over the api. Once that works the DSP port should be done in principle. It might be a good idea to do some small refactors before merging. What comes to mind would be removing some compiler warnings, removing some unused code and converting some macros into actual functions.

[PaulHaeger]

Another status update:

The DSP Port is almost done now. Switching to a different factory preset is a bit funky as of the moment but I think that issue is in the reading of the preset file. Everything else seems to work now.

I will also attempt integrating some of the value mapping functions found in DtBlkFxParam.h to the juce parameters itself. That way there will be less work to do in the GUI since meaningful values can be extracted and some DAWs will integrate that information into the automations as well, which is also a nice bonus.

For the saving of presets I propose using a XML based file. That seems to be the easiest and most robust way of doing this. That way I can just dump the parameter tree directly. Since I have written a function that can read files in the original format, no old presets will get lost and will still remain usable. What do you think about this?

[danielmkarlsson]

Amazing!
I am super excited!
Would love to beta test at any time you would like that.

Sounds great about presets from way back when working in the future.

One thing I've thought about is how the regions of the FX type are mapped towards MIDI CC's are not using the whole range and if you send CCs to the unused parts of the range the plugin can crash wildly and drag your DAW down with it in the fall.

0 to 35 and 44 to 103 as well. The two unused regions are 45 to 102 and 104 to 127.
Sorry about throwing this in weirdly in this thread all of a sudden here and I should have made an issue or something. I'm sorry, I just figured I should write this now immediately because otherwise I would never have remembered to do this properly later.

Much respect and love for the important work that you are doing.

[dozius]

For the saving of presets I propose using a XML based file. That seems to be the easiest and most robust way of doing this. That way I can just dump the parameter tree directly. Since I have written a function that can read files in the original format, no old presets will get lost and will still remain usable. What do you think about this?

I agree. Might as well take advantage of the built in XML stuff in JUCE for dumping/loading parameter information.

Thanks for the hard work!

[PaulHaeger]

A status update.

Ironing out the last issues with the parameters has been tougher than anticipated. I have started going through the classes responsible for the parameter logic and properly documenting them, so that I get a better overview on how things mesh together. So this might still take a bit more time than anticipated. As a plus side, at least some classes will have a proper doxygen documentation.

[segefjord]

@PaulHaeger bro you should set up a patreon or something, I will spread the word

[PaulHaeger]

Thank you very much for your kind offer, but that would be more trouble than its worth in my current situation.

I am still stuck on the parameter problem, but I think I understand what is wrong. Conveniently using copyState() and replaceState() for parameter switching doesn't seem to work how I have hoped it to work. When I manually input the parameters, then switching between programs seems to mostly work (sometimes replaceState() triggers some kind of assertion that makes things weird.) The issue seems to be with setting parameters from the code itself.

Looks like I have to store the parameters in a separate tree and update the values with a loop. At least I hope that works, else I am running out of ideas ...