Jamoma workshop Oslo October 2008

From FourMs

Jump to: navigation, search

Dates : 20-24 october 2008 Location: fourMs lab, University of Oslo

Participants :

  • Alexander Refsum Jensenius
  • Trond Lossius
  • Pascal Baltazar
  • Tim Place
  • Dave Watson
  • Nils Peters (via Skype)
  • Richardo de Pozo
  • Théo de la Hogue
  • Kristian Nymoen
  • Ståle Skogstad

Topic(s) :

  • Making Jamoma work
    • Review that core functionalities work. Below some points of particular importance:
      • Fix the issue with jcom.in providing spurious messagesDONE
      • Presets sometime stop working and require a Max restart
      • Review that function lib work as supposed to with jcom.parameter
      • Finish implementation of DataspaceLib for jcom.paramemeter (active unit | native unit | display unit)
      • Fix list bugs generated by Dataspace current implementation
      • Check that ramplib work with jcom.parameter
      • Check that level metering, muting, mixing, etc. work in modules with different number of in and out channels.DONE And WORK!
      • Check the jcom.in~/jcom.out~ overhead and review the optimization possibilities DONE
      • jcom.in~ and jcom.out~ do not work properly if they have different number of signals. See bug 2183044 and 1862780for further details.DONE
      • Examine the possibility for having local sends from jcom.return (in addition to the global one)
      • OSC:
        • Review if OSC instances work? - technically and conceptually - manage dots in OSC names (e.g. automatic naming)
        • How far are we towards the OSC namespace suggested in NIME and ICMC papers and the implementation of nodes?
        • How far have we gotten in terms of wildcards?
        • To what extent are we now able to query the functionlib, datalib and ramplib namespaces?
        • Discussion about post-OSC, in relation to the Virage project
      • ui/freeze doesn't work (bug 2181826)
      • defeat/meters doesn't work (bug 1997626)
    • Fixing bugs
    • Getting installers to work
    • Review feature requests, evaluate and implement the most important ones ?
    • Documentation
    • Demos
    • Vertical version of jcom.meter~
  • Discuss workflow in the group
    • Which directions are we interested in going
    • How do we get there?
    • Backwards compatibility
    • Possibilities for research funding?
  • Spatial sound:
    • Multichannel audio in TTBlue, or other alternatives to the jcom.multi.in hack
    • DBAP extension
    • IR reverb / convolver in TTBlue
    • From position dataspace to SpatDIF - how far have we gotten?
  • Roadmap for 0.6
      • Control of complexity in Jamoma ?
      • (multi-parameter control, like hipnoscope, etc... ???)
      • modules for high level control of other modules
      • Namespace and architecture
      • nOSC
      • nodes & (local) send/receive architecture
      • audio networks - how we pass audio, how we matrix audio, how we interface with audio functions
      • implementing wildcards?
      • additional ramp units (audio rate, using external clock, update when required for jitter, what scheduler do QuartzComposer use?)
    • Discussion, refinement, and drafting of ideas for the future
      • Jamoma 0.6 : algorithm/interface separation
      • publications (NIME09, ICMC09, CMJ, etc.)
  • Documentation
    • HTML and/or refpages?

Thoughts From Tim To make the best use of our time, we should clearly define the problems we wish research before we all come together in Oslo.

It is okay to have some broad topics to discuss, particularly at dinner or on the train (maybe we can work one day up in Lillehammer?). However, we will be most effective if we know what problems we wish to tackle, how the problem is defined, and how it can be broken down into smaller problems.

It is also important that we take a step back when designing our code to make sure we working at a conceptual level and not getting bogged down in discussions with implementation-level details. This will be important, for example, to make the cases clear for jcom.parameterview.

One model for framing problems is on page 83 of "Design Patterns Explained".

Personal tools