Recommended article for all VCV Rack plugin developers: Our new Plugin API Guide is your best resource for advanced development topics like polyphony, graphics, expanders, tooltips, data storage, and more.
25 Likes
Oh my! Looking forward to reading this and creating better modules. Thanks!
Very nice manual. Not that there’s anything wrong with it, but I’ll bet there’s a way to tell doxygen to use relative paths, instead of your home directory (/home/vortico/src/vcv).
Excellent resource, thanks Andrew!
Appreciate any expansions on the guide! Nice to have another page of info.
I think I have a lot of applications for a framebuffer. The example shows only the instantiation (the most boring part of using something), and could use expansion on the logic of drawing and lifecycle when you have a framebuffer as a component of your widget. A simple reference of API entry points isn’t very good for understanding sequence, orchestration, lifecycle, and runtime dynamics.
It might be worthwhile to mention which widget is a good example of using a framebuffer, and perhaps linking to it’s code on github.
I can of course search Rack and plugin sources for examples, but I appreciate a higher level description of the contracts rather than the specifics of the implementation of a particular widget, which is all you get from source. Writing effective docs can be harder than many people think, so I appreciate what we have.
I do have a small wishlist of missing bits of API that I’ve encountered so far as I build out my first plugin, but that’s a subject for a discussion with Rack support.
2 Likes
FramebufferWidget is a pretty simple widget, so there’s not much more to say about it than what’s in the Plugin API Guide. You just add widgets to it and call setDirty() when you need the framebuffer to be redrawn.
If you have any specific questions about it, I can answer them here or VCV Support.
1 Like
Thanks for the response! I’ll just have to try it and see what I need to do. Perhaps I’ll discover some good info that could be added, and if I find that, I’ll pass it on. I’m not certain how much performance I can improve using it and where it would be worth it. Certainly it comes with a cost in memory usage, and I wonder if it impacts the GPU memory budget. Perhaps there’s a rule of thumb on deciding when a framebuffer is worth implementing. I’ll need some more study on how to evaluate graphics performance, given there isn’t an obvious UI perf meter.
Ok, first question of the use of framebuffer:
It doesn’t have a drawLayer override. How do I get it to render to layer 1?
FramebufferWidget only contains 1 framebuffer, which renders layer 0 (calling the draw() method). It does not render other layers to its framebuffer.
That’s a shame - I was thinking it was a way to avoid managing the lifetime of an image handle and be efficient (create and destoy the image handle per draw, but use framebuffer to minimize this overhead).
People have requested the option to keep the image lit in my module when the room is darkened. I can still do that, and use the framebuffer with the option off, but still have to manage the image handle lifetime when the option is on, which is challenging because I don’t see a lifecycle event that lets me destroy the image handle, which requires the NVGcontext. I have a hack that references APP->window->vg in the widget destructor, but not sure if that’s supported or safe. I’ll probably find out when I get a chance to do testing in the VST scenario.
A FramebufferWidget to draw an Image to a framebuffer would be pointless. An image is a framebuffer, so you’d just be copying one framebuffer to another for no reason. Just draw your image on layer 1 if you want it to self-illuminate.