VCV show a shadow insdead of the panel

this is the first time am try to design a plugin, to avoid errors am using Rack-SDK, so after i have launched:

<Rack SDK>/helper.py createmodule <module slug> res/<module slug>.svg src/<module slug>.cpp

and add manually an .svg file for the GUI, launch make and make install and modify / add the strings in the .cpp and .hhp files. In VCV’s library i see a shadow with no other element and wen i import it in the rails i can moove it but there isn’t interactions.

Anyone can explane me why there is this mistake ?

many thanks to all who can help me. :slight_smile:

If you can share your svg and code, then someone can be more help. Onie of the first things to check is make sure your panel svg has a background rectangle.

I doesn’t knew how to share my .svg inside the blog, so this is the link to my dirve.

https://drive.google.com/drive/folders/1LhtweS-pG20c52IRdjzNpeSWcbwKyT9Z?usp=sharing

you can download from it.

aniways i have the components layer and the graphic layer, no other layers. many thanks

A common problem is to not load your panel itself. Look at the output log and see if it has anything interesting to tell you.

can you explane me how can i ceck it?

No, but you can google it. There is previous thread here on that.

You can find your Rack log file here:

  • MacOS: Documents/Rack2/log.txt
  • Windows: Documents/Rack2/log.txt
  • Linux: ~/.Rack2/log.txt

i have ceck, it create the plugin without any warning :frowning: aniways when i load the plugin what i see is a shadow and the 4 screws.

There’s nothing wrong with your SVG. If you replace one of the Fundamental SVGs with yours, it loads and displays perfectly.

The log file should mention that your module is loading the SVG, in a line that looks something like this:

[7.771 info src/window/Svg.cpp:28 loadFile] Loaded SVG C:/Users/richi/Documents/Rack2/plugins/Fundamental/res/8vert.svg

If you have no such line in the log, then possibly your module isn’t even trying to load the SVG. The line in 8vert that loads its SVG is this:

setPanel(createPanel(asset::plugin(pluginInstance, "res/8vert.svg")));

Do you have something similar?

2 Likes

ok, half solved:

with the helper.py strng i have call the file XYZ.svg when after i have call it XY.svg, so if anyone can’t see the panel probably there is a msscalling.

now i see the panel but it doesn’t show correctly the graphycs and doesn’t show connections even if the placeolder are placed in components layer. cecking the file helper.py see the placeolders, but VCV doesnt add the connections.

The SVG contains quite a few things that I don’t think nanosvg supports (e.g. mask, pattern, markers). nanosvg is the SVG parsing and rendering engine in Rack, and some of the limitations are mentioned in the Rack panel guide.

The reason your controls aren’t showing up is that they are being positioned far off the panel. A VCV Rack panel is 128.5 mm high, and you have the y coordinate of the first control at 3062mm. These coordinates are relative to the top left corner of the panel. This code does not operate in the coordinate space of the SVG: it operates in terms of pixels (more or less , but getting precise would mean a long discussion that isn’t very relevant).

    addParam(createParamCentered<RoundBlackKnob>(mm2px(Vec(4024.672, 3061.944)), module, Multiplesubtractor::VOLUME_KNOB_PARAM));

    addInput(createInputCentered<PJ301MPort>(mm2px(Vec(4024.488, 3147.055)), module, Multiplesubtractor::_IN_INPUT));
    addInput(createInputCentered<PJ301MPort>(mm2px(Vec(4024.58, 3201.889)), module, Multiplesubtractor::NONINV_IN_INPUT));

You’re not to blame for this – it’s what helper.py is generating for you.

I see that you have a very large view box set in the SVG. In Rack’s limited SVG support, I don’t think the view box is used.

i see how you got in this situation-- you’re running into the limitations of using helper.py, which simply transcribing coordinates from the SVG without understanding the implicit scaling that is going on with the SVG on a web page or in Inkscape, which do use the ViewBox.

I recommend setting the ViewBox in the SVG to be identical to the height and width (20.32mm x 128.5mm). Then you should be able to group everything on the panel and scale it down to that size. This will introduce a scaling transform on that top-level grouping element, which nanosvg DOES understand (but maybe not helper.py).

Since helper.py only really works for one-time initial bootstrapping (it will overwrite the generated CPP file each time), You can probably repair the SVG and fix the code and continue on and leave helper.py behind.

Personally, I use pixels in both SVG and code (not mm) (that’s a panel height of 380 pixels, and 1 HP is 15 pixels). I never have to use mm2pix conversions, and I can copy/paste coordinates between SVGs and code. That’s me, where I’m designing panels from thin air for the computer. It appears you are working from a physical module design where sticking to mm make sense, and all you need to solve is the scaling.

yep, I never used mm either, because none of the gfx editors I chose to use support mm. px is the way to do! I’ve also never used helper.py, although I hear some people like it.

Thanks for answering me and finding the problem. the module you see is a digitization of a hardware module that I had designed, to obtain the panel I had to export the 2D rendering with the internal function of EasyEDA and then modify it with Inkscape, do adapt the file for VCVRack, i made all respecting the measurements in mm because from what I had read VCV rack reasoned in mm, this speech of the pixels is new to me, if you then open the .svg file you will notice that the positioning is correct, and I really don’t understand what caused this off-panel repositioning.

in summary, so you advise me to work exclusively in pixels, or at least work in mm and then convert to pixels from inkscape?

“By the book” is to use mm, not pixels. It’s just that since so many tools don’t support mm many devs find if difficult or inconvenient to use mm. If your workflow is “mm friendly”, you can’t go wrong by doing it “by the book”.

Inkscape uses mm, which I believe the panel dev guide recommends using.

You can certainly use mm but you need to use mm2px in the code when you place the components:

This is from the Fundemental ADSR module code:

addParam(createParamCentered<Trimpot>(mm2px(Vec(6.604, 80.603)), module, ADSR::ATTACK_CV_PARAM));

Yeah, I know that. I have never used Inkscape, hence for me it is difficult to use mm. It think what I said is 100% consistent with what you are saying. Or did I mis-speak about something? (or maybe you were resounding to OP, and accidently replied to me. Happens all the time).

The fundamental problem is not mm vs pixels: it’s the scaling of the SVG due to the ViewBox, which AFAIK is not used by nanosvg in Rack.

OP should:

Set the ViewBox the same as the dimensions of the panel from:

<svg
  width="20.32mm"
  height="128.5mm"
  viewBox="3984.5 2988.9 79.999841 505.9045"

To:

<svg
   width="20.32mm"
   height="128.5mm"
   viewBox="0 0 20.32mm 128.5mm"

From there the SVG will need editing to re-scale all the elements to fit the size of the panel.

it may also need extensive surgery to remove things that nanosvg doesn’t know what to do with (masks, nested svg elements, et. al.).

It may be easier to start from a blank SVG the right size, then copy/paste an element at a time from the original, building the panel up to the desired result rather than attempting to reduce an original, very complex SVG coming from another set of tool down to what nanosvg/Rack can handle.

2 Likes

sorry am not a native english speaker, what you mean with OP ?

aniways now i doesn’t want arrive to have a perfect aesthetic resul, but to get to a point where interactive components (knob, jack, light) are showed, because i have modified the code copy/pasting the coordinates of all placeholder from inkscape to .cpp code, but now i still don’t see them.

p.s. you said that the displayed area is much larger than the panel, or that the panel is not to scale, but the file I created is of the exact dimensions in mm required by VCV and the work area is as large as the panel . Is it the fact of the complexity of the graphics that then offsets the conversion result?

That is “Internet slang” for “Original Poster” - you in this case.

1 Like