[Developer] re-cmake open source release

This forum is for discussing Rack Extensions. Devs are all welcome to show off their goods.
User avatar
pongasoft
Posts: 228
Joined: 21 Apr 2016
Location: Las Vegas

Post 22 Jun 2020

Hi guys

I am very excited to announce the open source release of re-cmake, the CMake based build framework for building Rack Extensions. Here are the main features:

  • native support in IDEs handling CMake directly, like CLion or Visual Studio Code (with the CMake extension)
  • project generation for most of the generators supported by CMake, like XCode for macOS, Visual Studio for Windows, Unix Makefiles, and many more
  • completely isolated build (no polluting the source tree)
  • much faster builds (due to proper dependency management, no need to recompile everything all the time)
  • proper integration with IDEs for debugging (for example starting Recon from CLion in debug mode and putting a breakpoint in the source tree)
  • native toolchain builds allowing for non sandboxed builds for easy development (use of std::string, std::cout, etc...)
  • easy to use script (re.sh for macOS, re.bat for Windows) to invoke all the various phases of the build so no need to remember long and complicated syntax
In addition to the framework, it comes with a "blank" plugin (does nothing but is fully wired and runs inside Recon and on Reason servers), which serves dual purpose:

1) documentation for the framework
2) a project that can easily be cloned to start your own rack extension: it contains all the boilerplate code and file structure and because it uses the CMake build framework, you only need to change the info.lua file with your own names (and CMakeLists.txt for the project name and this is where you add your own graphics and source code) and you are good to go..

Here is a screenshot showing a few things:
  • The project loaded in CLion with all the targets available
  • The source code of the "main" method (does nothing / empty)
  • The result of the native-install target run in CLion which has compiled and installed the plugin in its location so that Recon can find it
  • A shell showing the command that can be run on the command line to do the same outside the IDE
  • The plugin loaded in Recon
re-blank-plugin.png

Finally I wanted to thank David Antliff from Pitchblende who provided much appreciated help and feedback during the development process.

Feel free to contact me personally or use the ticket/issue on github for feedback, bugs, etc...

Yan
You do not have the required permissions to view the files attached to this post.

ForgottenClank
Posts: 106
Joined: 14 Nov 2018

Post 22 Jun 2020

Amazing, thanks! I'll have to look into this.
When you say "fully wired" I assume audio inputs/outputs and not much else, right? I would be willing to throw in my FX template which features much more functionality that new devs might not think they needed.

User avatar
pongasoft
Posts: 228
Joined: 21 Apr 2016
Location: Las Vegas

Post 22 Jun 2020

ForgottenClank wrote:
22 Jun 2020
Amazing, thanks! I'll have to look into this.
When you say "fully wired" I assume audio inputs/outputs and not much else, right? I would be willing to throw in my FX template which features much more functionality that new devs might not think they needed.
By fully wired I meant that all the pieces are in place for a fully functional RE (the GUI with its requirements like the tape for the name, the motherboard, the texts, etc...). In terms of actual wiring, it actually only has audio outputs (which I guess I agree is not what an effect should be but was thinking it would be easier to use as an instrument.. but if that is non intuitive then we can certainly change that.. it is not written in stone and can definitely be improved upon). Maybe it would be better to have re-blank-fx (with input/output + on/off/bypass), re-blank-instrument (with output only), re-blank-player, etc... so that you can pick the one you want.

In my opinion, re-blank-plugin is easier to use than any of the examples provided with the SDK because a) it is very very minimal, and b) it uses the CMake build which makes things simpler and easier to use. But of course I am biased ;)

User avatar
selig
Moderator
Posts: 8621
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

Post 22 Jun 2020

Dude!
Selig Audio, LLC

User avatar
jam-s
Posts: 1033
Joined: 17 Apr 2015
Location: Aachen, Germany

Post 22 Jun 2020

pongasoft wrote:
22 Jun 2020
Maybe it would be better to have re-blank-fx (with input/output + on/off/bypass), re-blank-instrument (with output only), re-blank-player, etc... so that you can pick the one you want.
That would be awesome.
If you're in Aachen, come and visit us at the Voidspace.

User avatar
Murf
Posts: 84
Joined: 21 Jun 2019
Location: Melbourne, Australia

Post 23 Jun 2020

Absolutely amazing Yan, I am going to convert all my projects right now...
Thankyou!

User avatar
meowsqueak
Posts: 37
Joined: 21 Jan 2015

Post 23 Jun 2020

Congrats on the release, Yan, glad I could help :)

You have done a brilliant job on this framework. It brings back the best of RE development workflow pre-SDK4 and has massively improved my productivity. I really felt like "upstream" dropped us in the deep-end with SDK4 (e.g. Mac debugging on non-Catalina didn't even work for... how many months?) but re-cmake has fixed pretty much every issue I had.

On the topic of different examples - presently the build framework doesn't really change much (if at all) between different types of REs. The re-blank-plugin pretty much shows off the full system. Having multiple examples doesn't really show off any additional aspects of re-cmake, it's all going to be much the same really, but they will increase the maintenance effort required to keep re-cmake up-to-date. Perhaps later when it might help with things like handling the lua dofile anti-support additional examples will be useful. That said, such examples could be potentially useful for other reasons, so maybe that's a good case for a more general open-source RE example gallery, where re-cmake just happens to be the common build system they all use, but maintenance is shared by others?

ForgottenClank
Posts: 106
Joined: 14 Nov 2018

Post 23 Jun 2020

meowsqueak wrote:
23 Jun 2020
That said, such examples could be potentially useful for other reasons, so maybe that's a good case for a more general open-source RE example gallery, where re-cmake just happens to be the common build system they all use, but maintenance is shared by others?
That was my thought. The examples are not well-functioning devices so maybe it's time for us to make some.

User avatar
pongasoft
Posts: 228
Joined: 21 Apr 2016
Location: Las Vegas

Post 23 Jun 2020

meowsqueak wrote:
23 Jun 2020
Congrats on the release, Yan, glad I could help :)

You have done a brilliant job on this framework. It brings back the best of RE development workflow pre-SDK4 and has massively improved my productivity. I really felt like "upstream" dropped us in the deep-end with SDK4 (e.g. Mac debugging on non-Catalina didn't even work for... how many months?) but re-cmake has fixed pretty much every issue I had.

On the topic of different examples - presently the build framework doesn't really change much (if at all) between different types of REs. The re-blank-plugin pretty much shows off the full system. Having multiple examples doesn't really show off any additional aspects of re-cmake, it's all going to be much the same really, but they will increase the maintenance effort required to keep re-cmake up-to-date. Perhaps later when it might help with things like handling the lua dofile anti-support additional examples will be useful. That said, such examples could be potentially useful for other reasons, so maybe that's a good case for a more general open-source RE example gallery, where re-cmake just happens to be the common build system they all use, but maintenance is shared by others?
Thanks David

I agree with you on the topic of different examples. It is true that re-blank-plugin was designed as the example/documentation plugin for re-cmake showing how to use it. It is a (nice) side effect that due to its simplicity (and use of CMake), it is a better device to clone than the ones provided with the SDK. But since it is not its primary goal, then it is indeed better to provide some other source for other RE examples to use.

User avatar
Zerosity
Posts: 109
Joined: 18 Jun 2015

Post 23 Jun 2020

I'm a non Audio/DSP coder and just want to say thanks to Yan and David for this work. Hopefully one day when I have the time to learn, this will benefit me. I'm glad RS finally listened and allowed devs to be free to share more of their work for others to learn/improve.

  • Information
  • Who is online

    Users browsing this forum: CommonCrawl [Bot] and 1 guest