How to create more durable VCS objects and layouts? Discussion/Proposal: Firm Widgets

Question

Firm Widgets (Proposal)

One of the features of Kyma – being able to quickly create hot values that display in a VCS is great for development of an idea but can also be a bugbear when working on complex projects or recombining existing work.

The issue is that VCS widgets and their layouts are lost when a hot value is renamed as is often necessary when recombining work. Existing solutions like the prefixer address the problem but not completely to my mind. The result is a lot of time is spent repeatedly formatting and setting up VCS objects and layouts.

Some good work has been done around this but to my mind VCS objects and layouts are still far too fragile and as a result, take up more development time than they should.

Keeping in mind that SSC may have something already in the pipeline to deal with exactly this, I’ve still been thinking about an approach to this issue. There will be some holes and gaps in this idea (I have a few ideas I havent described here just to keep this simple) and there may well be a better approach but here goes.

 

Short of a complete re-approach, I think what’s needed is a means to create and save VCS widgets and layouts as an object that can be handled more like other ‘sound’ objects in a Kyma sound structure.

I havent worked this out completely yet but to my mind there is some logic in modifying the Annotation prototype (if possible) to be able to contain new VCS objects I'll call 'Firm Widgets' and 'Firm Layouts', and extend or augment the VCS Editor with something like the 'Widget Table' as described below.

Firm Widgets

To create a hot value with a new firm widget put a colon* between the exclamation point and the hot value name eg. !:aHotValue.

*a colon is suggested as example, possibly a different character

When a Firm Widget is defined it is also given a unique identifier that cannot be seen or edited.

When the sound is compiled, the VCS containing that firm widget is also converted into a Firm VCS. A Firm VCS contains Firm Widgets and any other conventional hot values, the difference being once a Firm Widget has been defined, it (and the Firm VCSs associated with it) exist as objects attached to the Annotation prototype that will remain in the project even if its associated Hot Value gets deleted or renamed.

Widget Table

An extension of the VCS editor design: an editable table of existing VCS Hot Values and any Firm Widgets providing the means to convert existing Hot Values into Firm Widgets and see and edit the relationships of hot values as inputs and outputs of firm widgets.

In this table you could create new Firm Widgets and attach them as Child objects to an existing hot value or even nothing. One application here is creating a large version of a VCS Layout and then a small version that can be used as a sub layout or alternative layout but this would also enable mapping of a firm widget to an arbitrary number of other hot values and potentially setting up quite complex mappings (and can of worms).   

A Firm Widget has an input parameter: ‘Hot Value’, and an output parameter ‘Connected To’, both of which link by default to the hot value. Both of these parameters (or links) can handle being empty or broken which is what happens if the colon is removed or the hot value is otherwise renamed. Perhaps a broken or missing link could be displayed in a particular format if Kyma detects the break.

It makes sense that it should be possible to connect one or more Hot Values as destinations for a Firm Widget’s output. Using code in the input and output fields is also an enticing idea but I’ll leave it there.

I hope I've described this clearly, happy to discuss.
Regards,

Sean

Comments

Hi Sean,

I'm not sure about this, I think this can be rather complicated... On the other hand  I'm not forced to use it, and I like the idea of using the annotation class to control it. For me it wouldn't make much sense but it's difficult to tell how other people may use it.  
What I really like though is the idea of a Widget Table to quickly view and edit the VCS widgets. This is already available as a dropdown list in the VCS editor so maybe it's not difficult to implement a "table view".
just my two pennies...

---

I agree and simple solutions are my preferred option. I'm not particularly attached to any particular aspect of the solution per se.

I do think the present situation is already complicated, particularly when recombining work, to the point that it's worthwhile kicking around ideas to make the task simpler.

Another approach is not to worry about VCS objects and just tie them to an external soft or hardware controller, which is valid but underscores an area for improvement possible in the existing approach.

(Soapbox mode on ;)

A VCS is every bit as important as the structure it provides control over and it should be easy set up (it is) and easy to then save, modify and adapt as a more permanent object. Rather than at the moment where most of its components' existence are dependent on the particular string representing a hot value's name.

Hot values (and the development method they support) are great, but they are a poor foundation for work like this. Perhaps this is where we should look for the solution - a different kind of hot value?

(Soapbox mode off, thank you, thank you x :)

Answer 1

A feature introduced in one of the recent updates is quite useful. That is that when you have one Sound running and its VCS open, you can drag and drop a second Sound into the VCS window, and Kyma will copy widgets layouts over. This can be useful when you are developing versions of a complex sound.

Comments

ooo :)

Going to try that one out real soon!

Thanks Cristian