For a long time I’ve been building my plugins two ways - as a VCV plugin, and as a stand-alone command-line unit test program.
The unit test program does not link in any rack code, just it’s own code and c-runtime. I’m able to test all of the non-trivial parts of my module code, but none of the UI, and none of the glue code between my DSP and the real Module.
It is possible to make a regular command line program that links in Rack? If possible, is it easy?
Is anyone already doing this for their unit tests?
I haven’t really looked at how separable the bits of rack are. There’s dependencies that go back and forth between the ui and the audio library. Andrew has mentioned a headless rack in the next version which could presumably run as a non-interactive test mode.
it definitely sounds like concerns will be more separate after v2.0 - if not enough to be able to run it as a test harness, than still a lot further along.
likely best to wait and see to work past more general tests.
personally, I mostly do more general tests, as a lot of what I write is multi-environment: it’s a double edged sword - I miss some rack-specific things, but catch some bit-depth and “headroom” issues. I’d love a solution that could catch more use cases.
sounds like we are in roughly the same place re tests. Just as a simple example, I’d like to have unit tests for my json serialization code, but I don’t link the that stuff.
So far my modules’ glue code interacts with Rack entirely via vectors of inputs, outputs, params, and lights. So I can test the clue code using vectors of those things, without involving any other Rack stuff.
I suppose I benefit from writing modules that focus on control signals rather than audio, so my modules rely on nothing fancier than those vectors.
Of course, this leaves me with no automated tests for how my modules and module widgets configure the inputs, outputs, params, lights, and control widgets. I haven’t found a way (or tried very hard) to make my those things similarly independent of Rack.
If I wanted to do that, I’d probably try to hide all of the rack dependencies behind templates somehow, then write tests that supply alternate versions of the template parameters. Not having tried that, I have no idea whether it’s possible. But I’d try that before trying to link to Rack in its current form.
Suddenly I’m wishing for a version of the Rack SDK that delegates to Rack’s Module and ModuleWidget classes, rather than inheriting.
depends on what you’re testing. I like to test how my code responds to its inputs, foremost. if the inputs can’t be trusted, then I try to simulate the next step up, until I get to something deterministic.
2.0 should solve most of the deterministic parts, can likely embed a full test engine into a module. but, that just tells you the range of inputs you should have already have determined for your tests
2.0 should solve moost .0 should solve most of the deterministic parts, can likely embed a full test engine into a module. but, that just tells you the range of inputs you should have already have determined for your tests
Not directly related to this thread, but I have been increasingly using delegates in my ui. My component library contains a suite of menu items and buttons with std::function members that I can attach anonymous functions to. I have found it much faster to develop and maintain my code that way.
If I’m understanding correctly, you want to link to Rack with your own executable with its own entry point (main()) but not call Rack’s functions.
Rack v2 will be built as a library libRack.so/dylib/dll and will include a lightweight standalone executable Rack or Rack.exe that dynamically links to that library. Among other things, this allows you to link against Rack in your own standalone executable for running unit tests. However, doing this will be unsupported by VCV.
I think you’ll recall I did that for Rack 0.6 with ‘racktool’, because you helped in the debugging
https://github.com/rubyglow/racktool
The project is defunct now but I think it should work the same for Rack 1.x, but will be much easier/cleaner in the future as Andrew says above, because for Rack 2.x it will be built as a library. Good times.
The intention was not to support the possibility of non-Rack software to embed Rack, but that technical possibility isn’t too far away.
Commercial licenses could be a revenue source for VCV for using Rack in non-GPLv3 software, although I can’t imagine it’d be very significant.
Given the CPU cost it’s unlikely to be picked up for serious commercial use, but I was thinking more about small independent games and art installations that would have no trouble complying with the GPL
I manually add the header files in Community and look stuff up manually, when you add a .dll library it automatically links all associated files. Community has the solution explorer / filters (json folders) there is no limit to how many different versions you can have opened in a project in Community and because you add the solutions to the project the filters organise the files which can be in multiple places on disk. The filters also do not allow you to add 2 different version numbers of the same header file in the same solution. Just prefer to use community for these reasons.
Interesting. I do use community for my unit tests. I do (in theory) run them in linux and mac also, as I added a new target to my make file make test. But to be perfectly honest I rarely run it in those other OS.
