Duck typing buffers continued... Fri, Oct 3 2014 AM

Building off of the previous blog entry about duck typing streaming buffers, we got a chance to put the new functionality into practice by simplifying and improving some of the existing blocks.

Typeless utility blocks

The pacer block controls the rate of elements (and messages) through it using the PC clock as a rough rate gauge. The rate is specified in elements per second, so in order to pace the flow, we need to know the type of the elements entering the pacer block. But now, rather than specifying the type to the block's constructor, we can save a parameter (and some tedium) by dropping the type completely since the input buffer knows how many elements it contains.

There were quite a few utility blocks to simplify in this way:

• Pacer - paces the flow of streaming elements
• Delay - runtime configurable streaming element delay
• Finite release - output finite number of elements
• Copier - copy elements for buffer domain crossing

Typeless plotter blocks

The plotter blocks previously had an explicit data type that was homogeneous across all ports (when the plotter was used in multi-channel input mode). Also, each plotter had a bound conversion function and conversion function factory to deal with arbitrary input types - which was unwieldy and reeked of copy-pasta.

So first off, we added conversion functions for the BufferChunk to convert a buffer of primitives elements to any arbitrary primitive type. This puts the conversions into once place to re-used anywhere else in client code. Secondly, all the plotters now accept accept arbitrary input without the data type specified. This not only simplifies the parameters, but the multi-channel input ports can be heterogeneous. When its time for the display to be updated, input buffers are converted to the expected type (floats) with the new buffer chunk conversion routines, and then appended into the raster buffer.