[ardour-dev] logic to consider
vanDongen/Gilcher
gml at xs4all.nl
Wed Dec 1 16:41:05 PST 2004
On Wednesday 01 December 2004 15:45, Paul Davis wrote:
> This is the actual code, in its almost pseudo-code-like simplicity,
> that i am currently using to decide if we can configure a plugin
> insert to match a given set of inputs+outputs. A -1 value for either
> input or output counts means that we don't care about that
> setting. the 3rd boolean argument to the function means that we
> require an *exact* match on the number of inputs.
>
> the "set_count()" function multiplies the (hidden) instances of the
> plugin to get the required i/o counts.
>
> If anyone has the time and inclination to review this, i'd appreciate
> it. I've tried to comment it a bit more liberally than is my habit :)
>
That is a nice function.
But what determines how it is called?
Presumably you call it with out== -1 for a plugin inserted anywhere in the
plugin chain and then go down reconfiguring each insert.
The questions I have:
Is there ever any point in setting in to -1?
I only see that happening in a completely loose setup without any "hidden"
copies of inserts. Just add a plugin and let the user sort it out.
What happens to the unused "ports" when not called with hard_input_limit==true
or with in or out to -1? I imagine that they are discarded or fed 0.
But how is that made apparent to the user?
Closer reading of the code:
> if (in == -1) {
>
> /* we don't care about inputs */
>
> if (out == -1) {
We should never get here, because out=-1 is tested for above
<snip>
>
> /* we care about both input and output */
>
> /* require that the ratio of in/out requested matches
> the ratio of the natural plugin in/out.
> */
>
> if (((float)in/out) != ((float)inputs/outputs)) {
> return -1;
> }
>
From here on you ignore the hard_limit, or more specifically you assume it is
set to true.
The logic would suggest that if I have
inputs 3
outputs 6
in 2
out 4
I should get 1 plugin if hard_input_limit=false and it should fail if
hard_input_limit==true, now it will always fail.
> /* requested inputs+outputs must be exact multiples of
> natural plugin in/out.
> */
>
BTW, by "natural" do you mean the previous link in the plugin chain, or the
number of channels on the route?
> if (in % inputs != 0 || out % outputs != 0) {
> return -1;
> }
>
> /* from here on we know that any adjustment
> based on inputs will have the same effect
> on outputs.
> */
>
> if (inputs > in) {
>
this should have been rejected by the mod test above
> /* examples:
>
> in = 1, plugin = 2in, cnt = 1
> in = 2, plugin = 3in, cnt = 1
> */
>
> set_count (1);
>
> } else {
>
> /* examples:
>
> in = 1, plugin = 1in, cnt = 1
> in = 2, plugin = 2in, cnt = 1
> in = 2, plugin = 1in, cnt = 2
> in = 3, plugin = 1in, cnt = 3
> in = 3, plugin = 2in, cnt = rejected by mod test
> */
>
> set_count ((int32_t) ceil ((float)in / inputs));
> }
>
> return 0;
everywhere else you are returning set_count or -1.
--
hope this is helpful
Gerard
electronic & acoustic musics-- http://www.xs4all.nl/~gml
More information about the Ardour-Dev
mailing list