On Sat, Oct 03, 2009 at 05:15:59PM -0400, Simon Burton wrote: The normal way to evaluate a signal flow graph is a depth-first order traversal of the connection graph, starting at the outputs. If there is more than one output this requires some extra logic to avoid running a module twice or more if more than one output depends on it. The DF search can be done once and the result stored each time the connections change (as jackd does), or implicity run on each cycle (as AMS does). Correct. The run() method of a LADSPA plugin gets a single parameter giving the number of samples to process, this is the same for all ports. AFAIK there is no Linux plugin standard that supports resampling. Note that in the general case this takes more than just specifying a sample rate or number of samples per port. Assume you are resampling from 48k to 44k1, and your app is a jack client supposed to process jack_period_size samples at 48k in each cycle. Assume this period is 256. Then the resampled signal will contain either 235 or 236 samples. In fact it will be a sequence of length 5: [ 235, 235, 235, 235, 236 ]. The sum of this is 1176, corresponding to 1280 input samples, and 1280/1176 = 48000/44100. Now if these output samples are e.g. written to a file there is no problem. But if there is, further down the processing stream, a plugin that converts back to 48k then this plugin needs to know to the current index into the repeating sequence in order to be able to produce 256 output samples in each cycle. That means that the index into this sequence has to be a property of the 44k1 port type, shared by all plugins that use this rate. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.