Host example page

[nick-thompson]

This might be a stretch, but I think it'd be really cool to host the example page for a given module on component.fm. A lot of our current implementations have an example folder in the root directory with an index.html and such. I think for some cases the example page could be really interesting, and for modules where the demo plugin doesn't quite fit, hosting the example page would be a great alternative (i.e. hosting the spectrograph example page).

This isn't to replace the demo plugin, but to be implemented in addition. Thoughts?

[jsantell]

I was thinking about of some kind of solution for non-simple effect (in-out) components -- one would be a demo property with a URL in the manifest to indicate where, for example, the example/ directory is hosted, which would probably be the easiest implementation. Not sure where we could host all the pieces of an example page, possibly a different service that stored README/examples, but that seems like a bit much..

Also, second solution, was allowing custom UIs which could solve the issue as well...

Playing around with a custom UI for something like an EQ:

In this case, a parametric EQ would still just be an effect, and would work fine dynamically, and probably just have a lot of knobs on the default Rack implementation, but maybe the spec can also have a ui property that is a custom skin/implementation of Rack specifically for that module.

So web-audio-components/parametric-eq's manifest:

"web-audio": {
  "type": "effect",
  "ui": "web-audio-components/parametric-eq-ui",
  "demo": "http://web-audio-components.github.io/parametric-eq" // just an example of demo prop!
},

With the UI being..

"dependencies": {"web-audio-components/rack": "*"},
"web-audio": {
  "type": "ui",
  "parent": "web-audio-components/parametric-eq"
},

Should this even be a "web-audio" component? If the effect has which ui to use, then the visual component won't need to really be a web-audio-component (which makes sense, as Rack itself is not one).. Hrmm.

Also, now thinking that "effect" isn't a good type name, as it mainly represents a chain node, something that has an in and an out, like for example even the spectrograph is still the same API signature, hrmmm...

[nick-thompson]

I think I like your first solution best - let the user define a "demo" property with a link... anyone who implements a web audio component can just leverage github pages to host their own example with whatever resources they need, or if it's very complicated they can host it on their own server.

The latter solution sounds pretty complicated, and tbh, with the current state of web audio projects, I feel like anyone who would want a visible UI for a particular component would want to build it themselves so that the styling and representation would fit their app. It's a bit of a stretch to anticipate that people who want a UI for a module will accept whatever default styling the module implementer decided, I think. Of course, this solution opens the door for many people to implement various UI's with various themes for the same component. But then what would we do with all the various skins? Create a searchable repository of them? Maybe this is a possibility for some time down the road, but not now IMO.

I see this second solution fitting very well in an app which is like an in-browser DAW (which, if I remember correctly, a few people are working on atm), so that the DAW builders can just include default UIs with each component (just like VSTs). But the majority of web audio apps will be within a wide spectrum of awesome creativity, wherein people will be styling their own parameter controls to fit the app design.

That's my $0.02.

[jsantell]

Yeah, definitely pretty complicated.. and yeah, I had in mind DAW style manipulation -- for most demos, most controls are not going to be visible (based off of current culture of demos, that is), and just wondering how to get different skins for possibly the same component.. maybe down the road once we have a few implementations -- I can imagine clicking on a component (on component.fm), and all "UIs" that are made for that are listed there.. would be pretty hot, heh

[jsantell]

And also, Rack is done in a way to be customizable, and can drop in your own skin to modify all of Rack's UI stuff for all components, and then do specific styling for a single component if needed, but I guess I was thinking more of things that will have a canvas element and additional rendering constraints

[nick-thompson]

maybe down the road once we have a few implementations -- I can imagine clicking on a component (on component.fm), and all "UIs" that are made for that are listed there.. would be pretty hot, heh

That would be sweet, I could see that.

That's true, Rack is pretty customizable. I haven't made any modules that rely on a canvas, so I don't have any experience to go on there. I suppose if the UI had pretty complicated rendering constraints it would make sense that the module implementer take that responsibility away from the user by building their own UIs.

Hm I guess this is a pretty complicated situation..