Any interest in a (100% unofficial, third party) tour of Rack's codebase?

Hi all!

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).

10 Likes

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.

1 Like

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)
  • Stop 3: Rack’s DSP engine (engine/Engine|Cable|Port|Light|Module)
  • Stop 4: Interconnecting Rack’s modules (app/Scene|common; basics of event; most of widget/*; app/CableWidget|PortWidget)
  • Stop 5: Interacting with Rack’s modules (engine/Param*, Quantity, rest of widget/*, most of app/*, ui/TextField|Menu*|Tooltip*, rest of event)
  • Stop 6: Rack’s module bundling system (plugin; plugin/Model|Plugin)
  • Stop 7: Interacting with Rack itself (app/MenuBar|RackRail|RackScrollWidget|ModuleBrowser; rest of ui/*; history)
  • Stop 8: Misc. topics (TBD) and next steps

Low coverage (mentioned above when relevant)
asset, color, common, componentlibrary (and /res), helpers, logger, math, random, string, svg, system

No coverage planned

  • audio: wraps RtAudio; only AudioWidget, Core/AudioInterface (which uses AudioWidget), and the bridge code touch audio.
  • bridge and bridgeprotocol: unsupported and going away in V2
  • dep and force_link_glibc_2.23.h: details of dependencies in build process
  • gamepad and keyboard: simple MIDI drivers for these devices
  • midi and rtmidi: midi interface stuff
  • Core\*: plugins, not Rack code
  • simd\* and dsp\*: separate topics, used by plugins (also, simd is still changing)
6 Likes

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.

1 Like

@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 :slight_smile:

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.

2 Likes

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.

4 Likes

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…)

1 Like

So still happening?

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.

2 Likes