Good practices for describing a plugin to host in terms of preferred size, etc. + how a host should wrap a wam plugin

[micbuffa]

It seems that there is no good practices for a WAM developer to give hints about the preferred size of a plugin. Some plugins from the wam-example repo expose gui.properties.dataWidth.value and gui.properties.dataHeight.value for example (this is the case of the BigMuff WAM + others). Some developer add directly to the main div container a width and a height attribute etc.

On the other hand, are there good practices for a host in order to display correctly a WAM. Should the host wrap the WAM container in a div in order to give it a size (i.e the host decides in this case), or should the wam provide a div with a preferred size (in that case the WAM decides) ?

Michel

[boourns]

So, regarding plugin sizes, I think the following concerns should be discussed:

• how can a host (theoretically at least) provide a quality responsive experience for all device types, for example a host might support phone, tablet, and desktop screen sizes and ratios. On phone and tablet, controlling exactly when scrolling occurs is important to avoid dual scrolling situations where you have an inner and outer scroll bar for the same dimension.

• Should some plugins be resizeable? I have a few complex plugins that desire resizing, for example piano roll and any of the plugins that have coding elements (like function sequencer). If they're resizeable, should the host be able to save/restore their size? If so, who is responsible for resizing and how is that information saved in the host?

I think that's the primary concerns for managing the container that a plugin is rendered into.

For Sequencer Party I wanted a consistent experience managing each plugin, so I wrote a plugin wrapper that hosts each plugin GUI. That container manages resizing, positioning, and scrolling. When the plugin is loaded, the host tries to determine the plugin size and then sets the container to that fixed width and height. I could see an alternate UI for Sequencer Party on phones where the modules are all rendered in a single list to make it easier to navigate on phones. If each plugin was responsible for it's own resizing and container, they'd still have to have some way to tell the host about the resize (or make it part of the setState), and the resizing UI would not be consistent across plugins.

The downside of the approach I've chosen.. Hosts have to do a bit of work when loading plugin UIs to determine the ideal plugin size (since plugins just fill the container provided).

Things we could do better, if resizing is allowed, is we could indicate if resizing is supported in the descriptor.json. Then for example sequencer party would avoid allowing resizing for plugins that don't really handle it:

If plugins managed their own size and resizing, I'm not sure how I'd implement piano roll's inner resizing with how it works in sequencer party today. Also in a mobile context it would be harder to make a nice uniform "exactly full width / no scroll" experience that I think would be possible.