Tasks: type system

[jgottula]

making it work

• [x] class Block needs to store all of the ports in a map<string, Port *> so that debugging/GUI code can easily iterate over all ports and determine their names and types
• [x] Block subclasses will need to do REGISTER_PORT() to put them in that map
• [x] figure out how to determine what the derived type of a Port * is
  • e.g. if we have a InputPort<int> that is referenced thru a Port*, can we go backwards and determine that it is an InputPort<int> in a non-dumb way with some kind of runtime type info?
• [x] for now: in class Noodle<T>, use locks no matter what T is
• [ ] use the std::to_string function to convert unknown T to string for printf
• [ ] the fixed project will need to provide overloads for to_string
  • [ ] std::string to_string(const Fxp& value)
  • [ ] std::string to_string(const CFxp& value)
• [x] Ports will need a pointer to the Block instance that owns them
• [x] put template function definitions back into headers (or else: Port.h needs to depend on Port.cpp, etc.)
  • [x] maybe have Port.h and PortT.h (the latter has template function implementations)
• [ ] rename class hierarchies in a more consistent way
  • [ ] current: Port, IPort, OPort, InputPort<T>, OutputPort<T>
  • [ ] current: NoodleBase, Noodle<T>, QNoodle<T>, RNoodle<T>

    maybe

• [ ] if we keep class InputPorts and class OutputPorts:
  • [ ] make them have operator[const char *] which returns a reference/pointer to the Port instance with the given name (can throw exceptions of course)
  • [ ] rename InputPorts to InputPortSet and OutputPorts to OutputPortSet
  • [ ] use std::string rather than const char * as map key for m_names
• [ ] if we don't put port storage directly into block subclasses:
  • [ ] for faster access, a block subclass work function could have a static local variable: static auto in_port = inputs["theinput"] and thenceforth use in_port directly
• [x] rename Ports.cpp and Ports.h to Port.cpp and Port.h

  extra stuff we should probably do now while we're rewriting everything

• [ ] implement block groups (#27)
  • [ ] need to decide how this will work first
  • perhaps just do this by making a subclass of class Block that has other Block subclasses, whose work function just passes inputs and outputs between its top-level ports and its sub-blocks' ports?
  • or, invent class BlockGroup with yet another bunch of setup functions and stuff

    done

• [x] invent class InputPort<T> and class OutputPort<T> (probably subclassed from Port<T>)
• [x] move put get etc. into class InputPort<T> and class OutputPort<T>
• [x] change class Noodle to class Noodle<T> (use queue<T> with same type param)
• [x] class Noodle<T>'s from and to should now be OutputPort<T> * or InputPort<T> * pointers (no more Block * + index nonsense!)

  planning

• what if we put storage of the individual InputPort and OutputPort classes into the Block subclasss implementation?
  • pro: no need to deal with storage in InputPorts or OutputPorts
  • pro: no more string associative array nonsense; the ports are just named member variables
  • pro: maybe we won't need InputPorts and OutputPorts classes at all anymore
  • con: how do we connect noodles at setup time? would blocks' Ports need to be public so we can get a pointer and connect up the noodle?
  • invent class Connector; it will have one static instance with a static function that sets up all the noodles and stuff; every Block subclass will need to include friend class Connector (ugh)
  • we need to be extremely careful that the only thing Connector ever does with the InputPorts and OutputPorts is connect them up, otherwise we could really screw up our thread safety assumptions
  • possible solution to threading worries: make a strictly enforced "setup time" vs "run time" notion
  • con: probably not possible to get input/output port names at runtime (unless there's a super secret c++ abi thing for this, which I doubt)

[bgottula]

Wanted to double-check that the type system supports an important case I hadn't thought of until today. For some DSP operations, there is a notion of framing where data is processed in discrete frames with well-defined boundaries. In other words, not only does the block need to process N samples at a time, but those N samples need to be aligned to frame boundaries. Examples could include images, block codes, OSI Layer 2 frame structures, etc. For these types of DSP operations, it is more convenient to keep all the samples belonging to a frame together and pass them around as a discrete unit, rather than trying to attach some kind of metadata to identify the frame boundaries. For example, a frame could be a vector<int64_t> of some size. Noodles doesn't need to enforce or even know about the size of these vectors, but it would just treat each vector like it's a single sample. I'm pretty sure this should "just work," but I wanted to double check.

[jgottula]

I think it'll "just work". But I have been working under the assumption that we would be safe to use sample types by-value (i.e. copying and whatnot), which could potentially be slow/dumb for vector<>.

On Thursday, December 11, 2014, Brett Gottula notifications@github.com wrote:

Wanted to double-check that the type system supports an important case I hadn't thought of until today. For some DSP operations, there is a notion of framing where data is processed in discrete frames with well-defined boundaries. In other words, not only does the block need to process N samples at a time, but those N samples need to be aligned to frame boundaries. Examples could include images, block codes, OSI Layer 2 frame structures, etc. For these types of DSP operations, it is more convenient to keep all the samples belonging to a frame together and pass them around as a discrete unit, rather than trying to attach some kind of metadata to identify the frame boundaries. For example, a frame could be a vector of some size. Noodles doesn't need to enforce or even know about the size of these vectors, but it would just treat each vector like it's a single sample. I'm pretty sure this should "just work," but I wanted to double check.

— Reply to this email directly or view it on GitHub https://github.com/bgottula/noodles/issues/30#issuecomment-66679947.