Jamoma core

Topleft pop-up menu

• access to help file for the module
  Update: The message /documentation/help has been added to jmod.hub. It opens the help patch for the module. Still remains to include access to the message in the pop-up menu. Done
  
• add /defeat_meters to the menu Done. Implemented as /audio/meters/freeze.
  
• add a /recover or /screen_update message that will update displayed state for all parameters of the module. Done (Pascal suggests: Could a similar solution also be used to avoid feeding the coll #0_state continuously to reduce overhead in the modules?)
  

Topleft syntax menu

• Syntax messages should be sorted alphabetically. Done
  

Namespace

• Investigate if Jamoma modules could adopt the Integra namespace or at least the object-oriented philosophy of it as suggested by Henrik Sundt here. This would make naming of parameters more consistent, and would also improve readability of the html documentation as related parameters would be listed in sequence due to alphabetic sorting (e.g. /filter/cf, filter/gain /filter/q, /filter/type).

Ramp modes

• Ramps driven by
• line
• line~
• incoming video frames ramping in a set number of frames
• incoming video frames ramping in a fixed time interval
• Various ramping functions
• Modules driven by external clock

jmod.parameter(.gain)

• Add new attribute @priority for setting pattrstorage priority.
  

OSC

• Implement dynamic routing according to the OSC /* syntax

Mapping module

• A thorough review of the whole concept, implementation and specification of it
• Can mappings be done using either pattrforward of unique pairs of send/forward/receive to reduce overhead? Most likely it will be possible to use the OSC namespace to dynamically create such unique send/receive pairs. Done.
  
• Review the solution made by Pascal for "Z" and adopt any solutions that might improve the current implementation.
• Reviewing how autoscaling of parameters is done.
• Can the @range of the parameters be polled and used for autoscaling?
• Could something similar to lp.scampf be used as a standardised mapping function? If so, could this also resemble the different ramping functions implemented for rampenabled parameters?
  
• Could something like tap.smooth be used to offer standardized optional smoothing of data?
  Alexander suggested using slide object, that is in the standard distro, and also separating up and down smoothing. Looks like a better solution...
• It could be quite time-saving and handy to have range values, clipmode, rampmode automatically feeding the mapper when a parameter is selected... With, obviously, the possibility to change them to other values. (refer to the description of my mapping system). Trond said it was possible, even if not yet implemented... (How then to avoid parameters to return names and values when not handled by the user? Mousefilter?)

Externals

• Port tl.velocity, tl.delta and tl.delta2 to Jamoma.
• avoid NaN? and Inf fro  happening
• Port the tl.objects butterworth filerts to Jamoma, preferably by first adding them to blue.
• Look into and solve potential denorm issues
  

Audio modules

• Could audio levels as monitored by jmod.meter~ be accessible as a jmod.return? That way envelope following would be easy to use as input to mappings.