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
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.
Good idea for those that may really be interested but are pressed for time doing other development right now, myself included.
If you had C++ along with the other notes, I can’t see how that is bad. Remember always newbies become oldies.
I would appreciate this very much if you did it! I could then take chunks in the free time.
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
Comments (and better ideas) welcome before I begin!
Stop 1: Rack startup, shutdown and environment (
Stop 2: Rack’s general architecture (
app.cpp and associated concepts;
Stop 3: Rack’s DSP engine (
Stop 4: Interconnecting Rack’s modules (
app/Scene|common; basics of
event; most of
Stop 5: Interacting with Rack’s modules (
Quantity, rest of
widget/*, most of
ui/TextField|Menu*|Tooltip*, rest of
Stop 6: Rack’s module bundling system (
Stop 7: Interacting with Rack itself (
app/MenuBar|RackRail|RackScrollWidget|ModuleBrowser; rest of
Stop 8: Misc. topics (TBD) and next steps
Low coverage (mentioned above when relevant)
No coverage planned
audio: wraps RtAudio; only
Core/AudioInterface (which uses
AudioWidget), and the bridge code touch audio.
bridgeprotocol: unsupported and going away in V2
force_link_glibc_2.23.h: details of dependencies in build process
keyboard: simple MIDI drivers for these devices
rtmidi: midi interface stuff
Core\*: plugins, not Rack code
dsp\*: separate topics, used by plugins (also,
simd is still changing)
Thanks, all! Got held up by day job, dev work going slowly, etc. but I’ll tuck in to this next week.
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.
Hi all–life got hectic but I’m still planning on doing this (although it’ll go slowly…)
I’ll start as soon as v1.1.0 is released.
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.