Skip to content

development guidelines

Joe Steccato edited this page Nov 2, 2023 · 1 revision

todo before creating a ppooll act:

  • avoid redundancy: check if there is already another act that does (exactly) what yours does.
    if yes, see if you can extend an existing act before creating a new one. check back with the original authors / the developer team first.
  • quality over quantity :)

ppooll styleguide:

  • use ll_number objects as ui where possible instead of regular number boxes or sliders and dials
  • use ppooll preset field instead of max presets
  • put all processing into subpatch where possible
  • use ll.r, ll.p or ll.mc.r~ receives instead of regular max receives.
  • make patches as cable-less as possible
  • make patches mc-ready if possible
  • choose unique name for act to avoid conflict with existing externals / patchers
  • try to save screen estate by making patcher window reasonably small
    (tip: tetris helps with organizing ui)
  • keep ui clean (look out for orphaned elements in the back)
  • recommendation: group elements by color
  • create tetris default layout
  • incorporate ll.syncs to provide tempo syncing across ppooll (and external apps)

todo before submitting a ppooll act:

  • include .maxhelp file
  • include authorship and license information
  • review included code for their license. if the license conflicts with ours (mit license) remove externals from ppooll repository and get in contact with dev team. if possible such externals should be included as link to package-manager installable packages in ho_st info.
  • add act description to act_overview.json