Fun visual module idea.

I just had what i deem to be an interesting module idea.

It basically builds on stoermelders glue module concept where you can stick labels on things, but instead of a label you could stick images that youd load in.

Basically: Stickers on the rack.

I think of people like @dan.tilley and @purf and how much their visual modules have shaped my interactions with vcv and it seems like a fun module to conceptualize.

(I mean just think about putting ai art stickers all over your modular.)

Super trivial idea possibly but i certainly think its compelling, and might add to those of us who perform with vcv shown to the audience

1 Like

Its a straightforward extension to show an image versus drawing some text.

Interesting, certainly it is possible.

For me the main question would be what other features the module has, so that the workflow makes sense.

If you use the same image more than once, for example, would all instances of it be the same scale and orientation, or would there need to be some sort of controls to edit each sticker.

Do you have to select the image file from a dialog every time you add a sticker, or is there some way to predefine a bunch of stickers first, before you place them into the patch.

Can/Should the module save the image files, or just load them locally.

Its not at the top of my TODO list… yet, I could be persuaded it is a good idea perhaps… keep it going :thinking:

1 Like

Ooh, +1!!

I’ve made some stickers over time, actually, to put on computerscare’s Custom Blank, but of course they are images with a sticker in them. So for every sticker I make a large blank panel and I would LOVE to not having to do that! :smiley:

1 Like

@dan.tilley I think orientation and scale are definately important controls per instance of a given sticker. I honestly think that the way the stoermelder does it is perfect tbh, ill have to relook. As far as storing image files… i dont know how computerscare does it but i often reload patches and the links are broken… id vote for something that loads images, then saves them into the patch if possible. So say i load a.png then use it at dofferent scales 3 times on the rack, and load and use b.png 2 times, saving the patch would save a.png and b.png one time into the patch. Idk if that makes sense.

Im not sure if thats possible or reasonable spacewhise, but i always prefer embed vs links. Maybe its an option in the context menu for those who do/dont care about saving space. (Of course theres always the option to not use it…)

So Load unique stickers from anywhere on computer, but save them and the way they are used into the patch…

@purf Yes i imagine designing png files that can be placed anywhere, or used to reskin entire modules if you were so inclined and so obsessive lol.

Edit: i just saw this @dan.tilley “is there some way to predefine a bunch of stickers first”

Is there a way to add a folder into the vcv files where you could drop assets to then be loaded from? That way any stickers you design are always appropriately linked, and you have a dedicated place for all your stickers? I feel that that would certainly work also, and perhaps be more elegant of a solution. Is this even possible? What do others think?

This is how my custom panels work, the module creates a folder in the user directory and you can just put the image files into it then they show up in the context menu.

Thats not really feasible, unlike with Purfenator, the images would be rendered on top of the modules layer, but under the cables. Although I think you can make mouse events pass through the stickers, they would cover up all the module controls.

1 Like

If done like stoermelders, i believe they go under knobs and jacks, on top of panel. You could make a sticker that included labels for knobs etc.

Nope

Aah i see. It had been a second since using that. Hmm.

I assume there is no way to detect knobs and such to draw under them?

If the stickers are part of the widget hierarchy of the module, then it would be possible to place them elsewhere in the Z order. The trick is knowing where you are, because each module can have a very unique arrangement and implementations that do not necessarily derive from the Rack widgets. So, you’d need some placement UI that could move a widget up and down the hierarchy of the target module.

If a module uses the Rack SvgPanel for its panel (and not all do) it would not be difficult to replace the panel graphic at runtime. But then a user can already do that by replacing the SVG in the module’s res folder.

My svg_theme library shows one way that svgs can be themed, but this requires suitably authored SVGs.

A module could draw between its own panel and controls, but I am not aware of any way for a module to draw between other modules layers.

It is either under all modules or on top of all modules. And in addition it draws under lights (or on the same layer if it is drawn as a light, in this case what overlaps what is determined by which is added to the patch first.)

It might be possible, but I suspect if it is, the implementation would be pretty “hacky”. (Like maybe inserting a new widget into another modules widget, but then you would have issues with the modules box possibly).

Ah, was typing as Paul was… but we are essentially saying the same thing.

Ultimately I think the stickers idea is a good one, but reskinning modules is something different and not a good use-case for the stickers.

If you could get all devs to adopt either the svg_theme lib or to implement something like my custom panels, then you would have a easy time reskinning modules, but until then I think you are stuck with editing the plugin resources.

By the way, if any dev is interested in my custom panels, let me know and i’ll write an explainer…

1 Like

You can insert a widget anywhere in the parent-child hierarchy, and these draw in a specific order. If you could find the panel, you could add a child that completely covers that panel. For a module that does its runtime drawing in the panel implementation, this drawing would only show where the inserted widget left it transparent. For a module that does it’s drawing in the ModuleWidget (which I think most modules do, but that’s an unsubstantiated hunch), the drawing would appear on top of what was inserted.

So, yeah, it wouldn’t work everywhere. Plugins are just too diverse for any particular strategy to be reliable.

1 Like

It might actually be fun to try creating a panel injector module, you target another module in the patch and it tries to determine what each widget is in the hierarchy, then just whacks a new image widget in there…

1 Like

For modules that use a stock Rack panel widget, then it’s easy to replace the SVG in place - no widget injection required. (ed:) You could do the same for anything using standard Rack widgets that are SVG-based and have no runtime drawing other than flipping frames (button/switch) or rotating a component (knob).

This would work great for Fundamental and Core. I think Squinky’s and many others just use stock Rack stuff. Doesn’t work for those with more custom UIs like yours, Stoermelder, mine, …

Sure, but if you inject a widget, then you can have an on/off button on the injector module to flip between the default panel and the new panel…

Could be useful for tutorials perhaps, the new panel is mostly transparent but highlights certain controls or has arrows pointing at specific parts of the module, etc…

get youself comfortable with the methods draw() drawLayer() and drawChild(). The whole thing is a bit tricky, e.g. there are layers for cables, shadows etc.

Knobs and buttons are children of the underlying ModuleWidget, but in some cases children could also have children …

From my personal perspective, I simply would use graphics on the background of the rack (e.g. Purfenator) or graphics on blank panels (e.g. Custom Blank) to avoid lots of headache and keep on focusing on making music or on making modules for making music :sunglasses:

1 Like

That’s cool. Flipping would be fundamentally no different than injecting. You’d just need to remember the original SVG. These are all cached std::shared_ptr.

What’s saying that you couldn’t have multiple “algorithms” to decipher what area to inject layer.

When one doesn’t work, a user could context menu and select another method.

From my personal perspective, not that you asked:

VCV is a creative environment. Simple as that.

You are free to create the music you want, the modules you want, the interfaces you want, the performances you want, the experiences you want.

Dreaming of using vcv the way i think its best used (creatively) is certainly not less valuable than Making music. Otherwhise Why make modules, why make patches?

This is a nerdy synth playground at the end of the day, its ok to have fun.

1 Like