class MySystem
{
	...
	bool transparent;
	bool sampled=false;
	...
	void sample()
	{
		sInput = *input;
		sampled = true;
		if(transparent)
		{
			update();
		}
	}
 
	void update()
	{
		if(sampled)  // avoid double update
		{
			sampled = false;
			output = ...
		}
	}
	...
}

This also makes the flag sampled necessary. Becaus the normal clock master calls every sample() and then every update(). A second update-run shouldn't change anything, but consumes perhaps unnecessay processing time. ==== Properties ==== A Snaiks component can have properties. For example: * monoflop period * schmitt trigger limits * saturation limits * corner frequency or filter-type of a digital filter * filter coefficients * gain value * value of constants A property consists of * a value * a name * a persistent initial value * a setter method * a getter method * a method to store a changed value into the persistent memory ==== Info-System ==== A system generated by Snaiks should be fully discoverable and manipulatable during runtime. === Use cases === * change filter characteristics * change regulator parameters * adjust offset or gain * change system constants * change enable/disable flags * reset a component or the whole system * start/stop recording === Needed Features === * list inputs and outputs of an object * list properties of an object * change property values permanently ==== Hierarchical Systems ==== It should be possible to combine a set of systems to a sub-system, where new inputs and outputs are defined. KiCads hierarchical schematic structure could be used out of the box, but in C we do not see anything from this. Similar to the KiCad PCB layout, which also doesn't know anything about a hierarchical sheets. Altium Designer has the so called rooms, which group and synchronize footprint arrangement and traces between multiple instances of one hierarchical sheet. For the systems we should make something similar to the properties, which live in a SnsPropertyContainer. We should make a SnsSystemContainer, which provides on one hand memory for the different objects of a sub-system and on the other hand new inputs and outputs. ==== Any-Type Inputs/Outputs ==== Perhaps it would be useful, that not all inputs must have the same type. For example a mute gate, where the enable is bool and the signal is double. Pros: * more flexible systems Cons: * every pin must have a type specified in KiCad (could be done with net-annotators, similar to PWR_FLAG). * we cannot use a simple template-interface class any more, such as the SnsHybrid or SnsNumeric. === Proposal === * in cases, where this is really needed, a specific C++ class could be implemented * mixture of numbers and bool shouldn't be any problem