-
Notifications
You must be signed in to change notification settings - Fork 3
Workshop BEK March 2014 Sunday
Present: Trond, Pascal, Adrian, Henrique, Théo, Nathan
We started our discussion at 11:30. Trond began leading a review of the agenda items that were collected on the wiki page in the months prior to this workshop. First priority was to list all topics that need to be covered and then work through when to cover them.
Around 12:00, we transitioned to talking about how we should structure our days during the workshop. We decided to place discussions in the middle of the day with lunch and leave extended time for coding before and after. The time allocation ended up looking like this:
- 0900 - 1200 Coding
- 1200 - 1500 Lunch + Discussions
- 1500 -> Coding
- Evening : Dinner
We quickly identified the externals, model & views section of our topic list as where we needed some immediate discussion, because several people need decisions to be made on these issues to begin coding.
A key issue ended up being the function of outlets in the j.remote object and we looked at the view of jmod.filter~ as an example of where the first and second outlets are both used. The second outlet is useful when connected to a UI object that controls multiple parameters and should be kept.
It has been decided that the default behavior for the highlight feature is that it works from the first outlet. If the UI object is not connected to the leftmost outlet, the 3rd outlet can be used instead.
After an hour break for lunch, we resumed discussion at 14:30. The first topic was arrays, and whether to support/implement integerArray & decimalArray. The concern centered around the confusion between these two types and the idea that we could. A sidenote was made about the need to better document the various datatypes in the tutorials.
Do we need integerArray at all? Earlier discussions suggests yes, but without very strong use cases. It’s not used much currently in 0.5.7, only for MIDI messages and channel setup in the sur.output~.module. Another possible use case came up: Describing pixel pairs in matrixes (.e.g. 100 120, and we probably want to describe them as integers). Porting DataspaceLib+FunctionLib+RampLib integration to Jamoma 0.6 doesn’t depend on this issue being solved first, we can do the same as we did in 0.5.7: first work on @type array, assuming only decimals, and later find/replace array => decimalArray and additionally implement integerArray. Nathan also raised the possibility that maybe we don’t need to distinguish between integer and integerArray if j.parameter and friends now internally use TTValue, as this can be expanded easily from single value to arrays. We’ll keep this discussion at the back of our minds while doing the run-though of C++ code.
At 15:00, we shifted to an issue that Pascal raised regarding priorities in models. The essential proposal is for a j.node object that would allow users to set attributes for a group of j.parameter objects.
Our conclusions concerning j.node :
- no alias
- j.node doesn't parameters to its address, it just declares attributes for a node
- wildcards can be used
- subnodes can be used (e.g. [j.node some/sub/node])
- if a parameter with the same name exists, j.node is discarded (j.parameter wins)
- side-effect : priorities of parameters are declared for the last node only e.g. : [j.parameter some/sub/node/param @priority 2] -> priority only applies under the "node" node (and competes with other children of the "node" node)
The example patch we built during our discussion follows here:
----------begin_max5_patcher----------
559.3ocyW10aaBCEF9Z3WgkulkhMeDxtYs+G1cUUSFvI3HvFYLcIqp+2m+Hz
w5hnroIHRIfNu19X6G42CvK9dvbwIZGD7Yvi.OuW787rRFAuKwdvFxohZRms
avBQSCkqfAt1TzSJq9WqXc.8OwyTorulVBxOCTUTvwMsDIogpnRvdgzp0oiA
bQIcHM0LNsPzys4J5hHuugwqoJ6DitHtWdH2DGtIbPQvUcrePs8B+lrdzhd0
vvGTy6yyqoiSXKQUTw3G9ljVnbjHBsaSR.HxLG.Th8VZ5lPvS+VV5Xk1Lgun
xJsjPje7SnL3nUGWucsM8fjQpglFd022bIXlTmS+tNs+AzGy17pdF39VISHY
py.DbRJNGlMrubRpysTGdfv.8+2fwU.Xb1NCy143m8FNbD+FSpzkmTDI3dy1
ATRKXMj5QXCqagb.T0W8kaA.lZQ2toIXxBQvFsgsdMoBJFashYlqwSCkk9T0
CRI4r9n0gxxxGie5tNgV1r9uJvv+M.KZRfMyiRQ3sVdgRlDagKD2LE+cFwOn
h0+TU9qUSOB+KGEBOIERViRR2oehR03JQqoSKIJxwIWI7sS50hWIbQptEPjq
NDBkMEhhVRa0dg3COG8+xVco5BZGZF9pk+Q8ZT7deE5F3PCFGOCe01UBW2D9
Jr60tQnsSgnY9Z11gBIss5ONoiI3VJYXjlPGERSXZfMjwcg1MKTRelMz+sVE
hTudU5EauzMWmxR0yjddd0+mckTKUC
-----------end_max5_patcher-----------
Discussion was concluded at 16:00.
In previewing some of our topics for Monday, we determined that it was not desirable to sync with the umbrella repository via scripting. Instead, we want to be better about syncing to the umbrella on the dev branch once a feature is complete. Since we also want to move the documentation up to the umbrella repository, when can then have it re-build whenever a new commit is made on the dev branch of the umbrella repository.
Tim joined us in the late afternoon after his flight arrived. He reviewed the minutes from earlier in the day and had the most to say about our discussion of integerArray & decimalArray. His determination was that in the short term, we should just do array (with it behaving like decimalArray). In the long-term, we should look at a possible matrix type and possible harmonization of types between the core and the Max interface.