With the V1 API stabilized, I’m going through the codebase and taking notes on it. (I doubt I’m the only one…)
Without a lot of additional effort, I could turn those notes into a quick, unofficial, high-level tour of the code as it currently exists. It wouldn’t be comprehensive but hopefully (with some community support) it would be basically correct. I would try to time it so that it would be published, in draft form, before the V1 release. Obviously, I can’t guarantee that it would stay updated, but if it proves useful I would try to track at least big changes.
Now, it may be that everyone who would be interested in this already has enough C++ that they don’t need it, in which case I’ll keep my notes to myself. But if nobody thinks this is a bad idea, I’ll post Stop 1 (the main() function) below in a day or two to give a sense of what I have in mind.
My preliminary idea is go to through the App singleton and its members next, then Engine_run, then window and GUI/event interactions, and then the plugin/module system. I don’t plan on talking about MIDI, Bridge (which is on its way out anyway), the fine GLFW/OpenGL details, the web API, or the multithreading implementation in any detail, since I don’t think knowing those subsystems is that helpful to plugin authors or people who want to mod the code. (One of the reasons I’m doing this is that I’m updating my module-hiding fork to V1, and I’m thinking about putting in a few other little things that will help my own QOL; to do that kind of tinkering without breaking anything, it’s really helpful to know where things are).
I’m interested. I just spent an entertaining day figuring out why my custom widget wasn’t getting events. It turned out it had subclassed from Knob rather than SliderKnob, so most of the long and narrow widget was ignored.
There is a comment in SliderKnob that would have clued me in to my bug, but that only works if I knew to go and look for it.
Next, I need to figure out why resizing the window does not reposition and resize my framebuffer-backed widgets correctly until I mouse up.
Just to be clear, I’m not knocking v1’s functionality or comments; it’s great. But an overview document that gave me hints as to where to look would be great also.
Hi all! Thanks for the hearts and comments. Sounds like there’s enough interest that I’ll at least get the project rolling. I’ve finished my first read-through and here’s my current plan for what I’ll include in what order. (This accounts for all files in /include and /src).
Comments (and better ideas) welcome before I begin!
High coverage
Stop 1: Rack startup, shutdown and environment (main, settings)
Stop 2: Rack’s general architecture (app.cpp and associated concepts; window)
It will have to pass through @Vortico but my suggestion would be to use Doxygen and put your notes in-line in the source. The next step after that would be to annotate classes and functions with oxygen comments to allow auto-generated SO I documentation.
@chaircrusher - Doxygen comments in-source would be awesome (although what’s already there is helpful) but I definitely couldn’t commit to keeping them updated, so I don’t think I’m the person to do that even if there were official interest. What I’m planning is more like a narrative tour. Thanks for the vote of confidence, though
Here a cross-reference to the current VCV Rack API doxygen: https://vcvrack.com/docs/index.html
I thought it could be useful to pin it in the context of this discussion.
FYI all–as was safe to assume, the hecticity didn’t decrease and I don’t have a timeline for this right now. I’m still interested in doing it but nobody should wait for it (or hold off on their own similar endeavor…)
Hi @Coirt! I am definitely still hoping to do this, but life has continued to intervene. At this point I’m going to wait for the V2 source to be released (pretty soon now, I suspect) since it’s got a new approach to the engine. Once I’ve read through that, I’ll put out another high/low/no coverage list and see where it goes.