<commit_before>% Roadmap for libmapper

This document contains information on what needs to be accomplished in
the library before a first release, and thereafter what features might
be added in the future.

Requirements
============

Before initial release, the library must provide the following:

* Allow defining a named device and input/output signals.

* Allow allocation of a unique port and name for the device.

* Allow automatically responding to GUI commands to set up routings
  and mappings.

* Allow monitoring of the network and querying of this information for
  display and user interaction.

Current Status
==============

The current status is summarized here:

* Name/port allocation works.

* A device and signal API is established, allowing polling of the
  network, responding to incoming signal values, and updating
  registered output signals.

* Routings (called Links) and Mappings can be established, and all
  required signal conditioning functions have been implemented.

* A device is able to also monitor the network and store information
  about other devices, signals, links, and mappings, and this
  information can be queried.

Tasks To Do
===========

The following tasks currently need to be accomplished before initial
release:

* Code review of the database API.  In particular, inconsistencies
  between terminology "input" vs. "source", "output", "destination",
  "target", must be cleared up.  Check clarity, as it is somewhat
  cluttered and verbose with various query types.

* Code review of the expression parser/interpreter.

* Adjust signal declaration syntax, generalize signal tracking functions?

* Ensure correct action is taken (if any) when signals are registered
  and unregistered.

* Separate network monitor from device, such that it's possible to
  monitor the network without creating a dummy device.  This may
  require creating a global context handle for example.  (Currently
  the database is the only global.)

* Create a concise but convincing example for both controller and
  synth sides.  Optional support for audio output, perhaps using STK,
  would be beneficial here.

* Allow selection of network interface.  This will also require
  changes to liblo.

* Make port/IP for admin bus configurable.

* Add API for requesting network information.  (Send a request for a
  device's namespace, links, mappings.)

Lower priority tasks<commit_msg>marked a couple of roadmap items as done<commit_after>% Roadmap for libmapper

This document contains information on what needs to be accomplished in
the library before a first release, and thereafter what features might
be added in the future.

Requirements
============

Before initial release, the library must provide the following:

* Allow defining a named device and input/output signals.

* Allow allocation of a unique port and name for the device.

* Allow automatically responding to GUI commands to set up routings
  and mappings.

* Allow monitoring of the network and querying of this information for
  display and user interaction.

Current Status
==============

The current status is summarized here:

* Name/port allocation works.

* A device and signal API is established, allowing polling of the
  network, responding to incoming signal values, and updating
  registered output signals.

* Routings (called Links) and Mappings can be established, and all
  required signal conditioning functions have been implemented.

* A device is able to also monitor the network and store information
  about other devices, signals, links, and mappings, and this
  information can be queried.

Tasks To Do
===========

The following tasks currently need to be accomplished before initial
release:

* Code review of the database API. 
  * (DONE) In particular, inconsistencies between terminology "input" vs. 
    "source", "output", "destination", "target", must be cleared up. 
  * Check clarity, as it is somewhat cluttered and verbose with various 
    query types.

* Code review of the expression parser/interpreter.

* Adjust signal declaration syntax, generalize signal tracking functions?

* Ensure correct action is taken (if any) when signals are registered
  and unregistered.

* Separate network monitor from device, such that it's possible to
  monitor the network without creating a dummy device.  This may
  require creating a global context handle for example.  (Currently
  the database is the only global.)

* Create a concise but convincing example for both controller and
  synth sides.  Optional support for audio output, perhaps using STK,
  would be beneficial here.

* Allow selection of network interface.  This will also require
  changes to liblo.

* Make port/IP for admin bus configurable.

* (DONE) Add API for requesting network information.  (Send a request for a
  device's namespace, links, mappings.) (DONE)

Lower priority tasks
{'fraction_non_alphanumeric': 0.0561015561015561, 'fraction_numerical': 0.0, 'mean_word_length': 4.327153762268266, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5477820', 'n_tokens_mistral': 1178, 'n_tokens_neox': 1124, 'n_words': 673}