Skip to content

Workshop BEK March 2014

Jump to bottom
nwolek edited this page Mar 8, 2014 · 124 revisions

Schedule

General plan

  • March 2-5: Jamoma 0.6 development
  • March 6: Jamoma BOD - How to administer the development effort and best structure workflow for the future?
  • March 7-9: Jamoma Core/C++ development

Daily allocation of time

  • 0900 - 1200 Coding
  • 1200 - 1500 Lunch + Discussions
  • 1500 - Resume Coding
  • Evening - Dinner

Minutes for each day

Topics for discussions:

Externals

  • DONE Should we get rid of the leftmost outlet of j.parameter and friends? -> answer is NO (see Minutes)
  • DONE what about an object for adding attributes (such as priority and tags) to implicit nodes - see #388
  • DONE With the model-view-controller separation in 0.6, is j.paramui now an anachronism? If this object is to make sense, it should rather be a j.remoteui. Do we want to update/alter and maintain it, or should we rather disregard of it?
  • DONE A walk-through of how messages are being processed between nodes . and in the process we should add Doxygen wherever needed
  • j.parameter - @type integerArray and decimalArray -> decisions are postponed to after the walk-through
  • See if we can reduce the number of attributes of j.parameter (or simplify the syntax). See discussion on redmine

Models

  • Friday A walk-through of how to build models and views in Max - link this to updating tutorial for this topic
  • DONE Interfacing with models hard-coded in C++. The noise~.model is an example of this, ref discussion in JamomaMax issue #343
  • DONE How do we label in~ and out~ instances in models? Ref this discussion -> .L and .R for stereo modules (+ .Ls .Rs .C and .LFE for surround models), numbered for other , non-standard, cases
  • DONE How do we disable some but not all audio amenities in a model (not in the view), ref. this discussion on the devel-list. -> conclusion is that it works the current way.

Views

  • DONE Highlight feature in views - demo of functionality in 0.6, and ensuring that we also keep the functionality that was implemented for 0.5.7.
    • For the whole view (like in 0.5.7)
    • For remotes
  • DONE What will be the best practice for reusing parts of views in a similar way to how models can be embedded in models? The OpenGL models (e.g., model.videoplane and friends) are examples of where it makes sense to have views within views. -> see j.gl.videoplane's inspector
  • Freezing views or individual remotes - more generally, how to address remotes in a view ?
  • Priority-recalling j.remote and friends

Video models

  • DONE Freeze and preview buttons do not work in video models, ref JamomaMax issues 522 and 523
  • DONE Are the j.in and j.out objects generic enough to cater of all kinds in signals, including jit.matrix, jit.gl.textures, dictionaries, FTM data types, or do we somehow need to discriminate. If so, should the name of j.in and j.out be changed to reflect their scope (e.g. j.jit.in and j.jit.out) similar to how j.in~ and j.out~ only work with MSP audio signals?

Surround models

  • DONE Should surround models be renamed from the current sur.foo~.model to foo=.model? YES !
  • DONE Trond believes that we need j.in≈ and j.out≈ externals. These work the same way on AudioGraph signals as j.in~ and j.out~ does on MSP signals. The new sur.limiter~ model is a useful example for when this might be useful. This needs to be fully implemented before Theo leaves. The design of these with respect to muting, bypassing, gain and mixing need to be discussed. Quite a few spatialisation models are mixing signals using various spatialisation algorithms. Even though the models have audio in and out, it does not make any sense to mix wet and dry, or to bypass the model. Ref JamomaMax issue 512
  • Friday JamomaMax issue 512 also indicates a problem with AudioGraph graph construction and muting that need to be examined.
  • Friday JamomaCore issue #16 indicates a problem with summing related to the front/back order of objects

Controlling models

  • How to monitor incoming messages to a model (or one specific j.message/j.parameter object). And related: Is j.message expected to produce output from the j.model object or not?
  • The "Edit current state as text" popup menu item of views need to be discussed. This was initially developed for the purpose of being able to edit cues manually, but the functionality of this menu item in 0.6 has been changed, rendering it unusable for the original purpose.
  • See how this articulates with cues and presets
  • Théo proposes to rename j.cue to j.state
  • Namespace selection round up for state storage (absolute vs relative storage, namespace selection)
  • Interpolation between presets: Mechanism for setting when during the ramp non-scalar values are to change from A to B.
  • DONE Should the control inlets/outlets stay leftmost (and signal rightmost), when the Max convention is the reverse ? This is a problem with models implemented as externals, and a possible cause for confusion for newcomers. It also seems now the last possible time to change this (before long), as 0.6 already induces a lot of backwards-compatibility mayhem... -> YES !
  • Should we discuss the OSC query proposal ? (based on OSNIP)

Documentation

  • DONE Documentation and structuring of help patches -> should we use arguments in help patchers modules ? (see discussion on the dev list). We devised an improved way of managing automatic naming/instancing of modules without an argument -> #537
  • NEEDS THEO Discuss the different method names (model:documentation/generate, model:reference/open) and potential unification of documentation/reference files (all in xml ?) and so on..
  • DONE Further work on the web site
  • DONE Question the different user bases/profiles of Jamoma for core objects/standard model libraries/modules… and determine which strategies we should implement, concerning different distributions, communication, documentation…

Maintenance

  • DONE Update/clean out files from the Tools folder.

Server automation

  • DONE Documenting the automation of nanoc rebuilds of Jamoma Web site
  • DONE Completing (if it's not complete already) and document the automation of Doxygen compiling on a regular basis. As this documentation depends on updates to all of the repositories, we might want to consider if it either is to happen when master branch of top-level repo is updated, or if it is to be scheduled, e.g. nightly.
  • Automate and document release builds as well as nightly developer builds

Future directions for development

  • Stian and Trond have started a wiki page for initial topics regarding how the user interaction experience with Jamoma models and views can be further improved in the future here

Cross-platform concerns

  • Windows

Jamoma BOD meeting:

How do we administer the Jamoma project in the future?

We need to agree on and adhere to best practise regarding:

  • DONE Git

    • Correct workflow regarding git branches (across submodules)

      • Would it be possible to create a ruby script that simplifies the process of updating the top-level repo when submodules are updated? Could that be automated? If so, would this be beneficial or not? Issue 120 -> Henrique: This might actually break the repository as the new submodule commits might break the parent repository, that is why its important to test it and then, "commit the submodule" on the parent repository, so it stays "locked" into a working version.

    • Should BOD minutes and other specifications be moved from Google Docs to GitHub wiki, so that we have it all in one and the same place (and so that it's publicly available, and linked to bug/feature issues, commits, etc )? -> Henrique: Is multi-user editing something relevant?

  • Testing

    • DONE Development of unit tests
    • DONE Systematically running unit tests to ensure that new commits are "good" before merging new stuff to dev branch
    • DONE Development of integration tests
    • Systematically running integration tests to ensure that new commits are "good" before merging new stuff to dev branch -> Henrique: Sounds like we would like to have a guy like this: http://dploy.io

  • DONE Doxygen

    • Always properly Doxygen-documenting new files when they are added to one of the repos
    • Always properly Doxygen-documenting new variables, classes, methods, etc. when added to preexisting files

  • Best model for development cycles

    • How can future development happen in many small incremental steps that avoids "breaking everything" the way we have experienced over and over again? -> Henrique: Long, boring and potentially useful: http://nvie.com/posts/a-successful-git-branching-model/
    • How do we organise development sprints in the future? -> Henrique: Using https://waffle.io/jamoma/jamoma could be a good starting point!
    • How do we assign version numbers to Jamoma in the future? -> Henrique: just adding this link posted on the list: http://semver.org/

  • Management of issue trackers

    • Some of our issue lists are getting long and need pruning. What processes can we put in place for removing "stale" items? Who decides when an issue has gone stable?
    • Management of tags and milestones

  • DONE Submodule and folder structures

    • Can JamomaTest be integrated into JamomaMax, reducing the number of submodules by one?
    • Can JamomaDocumentation be integrated into top level repo, reducing the number of submodules by one?
    • What's best practise for where JamomaCore iOS Xcode projects go, and how are they to be named? Currently some DSP extentions have Xcode projects with OSX as well as iOS targets, and others have only iOS. This should be harmonised.

Completing 0.6

Making concrete plans for finishing the 0.6 port.

Participants and dates:

Nathan Wolek:

  • Arrives 2014-03-01 12:15
  • Departs 2014-03-10 06:30 (early flight, so might need to stay at airport hotel last night?)
  • Hotel booked? YES

Tim Place

  • Arrival 2014-03-02 16:30
  • Departure 2014-03-09 10:20
  • Hotel booked? YES

Trond:

  • Out of Bergen the week before the workshop, planned return on the 1st

Adrian:

  • coming with a girlfriend
  • Arriving 2014-03-01 11:30
  • Planned departure 2014-03-12, spends the last few days on vacation

Henrique:

  • Arriving 2014-03-01 11:30
  • Departure 2014-03-09 19:00

Thorolf Thuestad:

  • Participating first three days (Sunday - Tuesday)

Théo :

  • Arriving 2014-03-01 16:30
  • Departure 2014-03-06 17:30

Pascal :

  • Arriving 2014-03-01 16:30
  • Participates until the 6th end-of-afternoon
  • Aurélie (wife) arrives on 6th-4:30pm
  • Leaves March 9th at noon by train to Oslo

Julien

  • Unfortunately Julien won't be able to participate... :-(

Two appartments booked

Both booked March from March 1 to March 9.

Flat 1:

  • Adrian +1
  • Henrique

Flat 2:

  • Pascal
  • Julien (leaving 6th)
  • Théo (leaving 6th)
  • Aurélie (arriving 6th)

Funding

  • Tim Place: Covered by BEK and GMEA
  • Nathan: Stetson is covering flight
  • Pascal: Funded by BEK
  • Theo: GMEA
  • Julien: GMEA
  • Adrian: Funded by BEK
  • Henrique: Funded by BEK
  • Trond
  • Thorolf: Based in Bergen
  • Eirik: Funded by BEK
Clone this wiki locally