Infrastructure for libraries

Updated May 12, 2018
  • ~/Bela/libraries/ containing subfolders (one per library)
  • #include <libraryname/file.h> (which actually lives in ~/Bela/libraries/libraryname/file.h
  • make looks for #include and checks if the folder/file exists and builds all the .cpp files in that directory, unless it finds metadata files in the folder that tell it to do otherwise
  • metadata file could have extra compiler/linker flags. This way they could include a shared library by having a folder with metadata file and .h and .so
  • have examples in libraryname/examples
  • "libraries" tab in the IDE: lists libraries, example projects
  • what happens when the user tries to include a library that is not installed?

Proper library classes

Updated Apr 15, 2018

Decently uniform API, better resource management

Proposed API:

Constructor(args){//nothing: you should call setup()}
... more stuff for message passing

Having both Constructor(args) and ::setup(args), as well as cleanup() and Destructor() doing basically the same thing allows for global objects (useful for the beginning user, who can call ::setup() from setup()) and for proper scoped lifetime.

Thread management: Library classes should create and manage their own threads, which should not depend on gShouldStop. The thread should be RT or NonRT depending on what it does (e.g.: if it does disk I/O, it should be NonRT). In fact, threads themselves should be abstracted out in a dedicated class. The destructor should:

  • tell the thread to stop
  • wait for the thread to stop
  • destroy resources
  • return To minimize the number of threads, objects of a given class may share a single worker thread (see current implementations of WriteFile, Midi).

Classes: Thread AuxTasks: AuxTask, AuxTaskLoop, AuxTaskLoopStr, AuxTaskLoopBuf, AuxTaskLoopPtr and AuxTaskLoopPtrBuf ... with appropriate inheritance ( or templates) ... and maybe called Thread instead

RtNonRtMessage <<< `sendFromRt(void*)` and `receiveFromNonRt(void*, int timeout)`