Workshop BEK March 2014 Wednesday

Wednesday, 5 March

Present: Trond, Pascal, Adrian, Tim, Théo, Nathan, Henrique

Cases:

You manually name every instance of every model with a truly unique identifier every time and never open 2 copies of the same patch, then you have no problems with instance naming. This case presents no issues.
You name nothing. For example, create a patcher with an input, several filters, and an output. Then take snapshots of the state with the cue script. For the snapshots to work when the patcher is re-opened the unique names generated for the model instances must be maintained across patcher saves/re-opening. Jamoma currently does not generate unique names (i.e. Jamoma creates /filter.1 and /filter.2 instead of /filter.8c5df) and does not save them with the patcher.
You name things with "reasonable" names. This means that if you open a help patcher or another patcher to look at etc. you may very well end-up with conflicts in the names. *Jamoma currently does conflict resolution on the names but you aren't informed about how it is done, the state of this is not saved with the patcher.

Discussion:

Can we address the 'no-name' case orthogonally from the 'duplicate' conflict-resolution case?
It was generally deemed to be "user error" or a "user problem" if you are in a situation where the names conflict. Tim is not convinced this is true, but for practical purposes it probably needs to be accepted.
How can we meaningfully notify the user that something has gone horribly wrong and they are screwed because the names conflict and we renamed the instances?

Brainstorming Implementation Details:

We experimented with several techniques for updating the text in the object box. For example, script replacing the object box with the new name. These various techniques all failed for one reason or another. It is very awkward because the object issuing the scripting commands is deleting the model that contains itself and then the node lib is in a state of limbo because everything disappeared in the middle of registering a model. This leads to crashes.
Another place we could save state is by using the varname attribute of the abstraction's box.
If we use varname and we can provide the name as an argument (as we do now) then one could potentially end up with a conflict between the two. If we separate the issues however, we could possibly only use the varname when no argument is provided. Perhaps it would always reflect the current name but just not change the behavior on load unless there is no arg?
We could also investigate using instance attributes to avoid the varname because there could be some conflict with varname auto-updating when you duplicate models and such.

Theo lead us through the C++ choreography involved in a simple patch using Modular.

Trond has promised to type notes later

Discussion was concluded at 19:00