What mechanism(s) is (are) available to ensure that parameter changes aresynchronized with the data to which the changes apply?
It is frequently required that applications process data streams in segments
whose beginning and end may be determined at runtime. Different parameter sets
may be associated with each data segment. Beginning with Version 3.0, Gedae
provides the notion of a valve. The key issue addressed with the introduction
of valves is the ability to efficiently implement embedded control. Valves can
be used to implement branch-and-merge, data segmentation, looping and data
insertion.
In addition, Gedae now provides the ability to pass parameters as a
run-length encoded data stream. This includes the ability to synchronize
parameter changes over multiple function boxes by connecting run length encoded
stream box outputs to parameter inputs. Streams and parameters are normally
quite different. Connecting box output streams to box input streams implies
data synchronization. that is , the down stream box cannot fire until enough
tokens have been placed on the input stream. Connecting output parameters to
input parameters implies no such synchronization. The range of an output
parameter changes the parameters it drives as soon as possible but there is not
actual requirement imposed other than change should occur.
Runlength-encoded streams provide the means of gaining the benefits of
parameters with the synchronization of streams. Since the box using a parameter
expects the parameter to be constant for the entire firing of the box, a box
can only fire with a granularity at most the number tokens for which the token
value is held constant. Runlength encoded streams naturally provide this
information in the runlength of the stream. When an encoded stream is connected
to a parameter, the box is fired the number of times implied by the runlength.
return to top
