I’ve been playing with the plugin host lately and I really like the approach. However, feedback loops in the graph don’t seem to work (whenever I close them no sound goes through the loop). Is there a reason for this?
don’t they? That’s a surprise, it was designed to cope with feedback…
Have you put in an overflow protection or something? Sometimes it seems to behave as expected, sometimes not, and I can’t really see a pattern at the moment. For sure you don’t get a signal that goes to infinity when building in an allpass loop (which is good, on the one hand side, but also makes me want to know how exactly the wiring works).
Don’t think I put any overflow stuff in there, but it’s a long time since I looked at the code, and I might be wrong about that…
I’ve found this piece of code in the RenderingOpSequenceCalculator:
if (bufIndex < 0)
// if not found, this is probably a feedback loop
bufIndex = getReadOnlyEmptyBuffer();
jassert (bufIndex >= 0);
Doesn’t this mean that the signal in a feedback loop is set to zero?
Possibly, I’d need to spend some time digging through the code to say for sure…
I’ll try the same…
I’m really lost here… what I’ve figured out is the following: when building the rendering sequence there is a loop through the plugins in the order of their creation in the host. In this loop the plugins are added to the array OrderedNodes (nodes eq. plugins) at either the end of the array or at the position of the first node that the plugin in question is an input to. The audio input, the midi input and the audio output are nodes number 1, 2 and 3, respectively. The OrderedNodes array is then used to build the rendering sequence.
Now if I add two plugins to the standard input-output configuration, these will be nodes 4 and 5. Say I have a connection from node 1 (audio input) to node 4, a connection from node 4 to node 5 and finally a connection from node 5 to node 3 (the audio output). In addition I want to have a feedback loop going from node 5 back to node 4. The OrderedNodes array will then be [1,2,5,4,3].
When building the rendering sequence for the OrderedNodes, buffers are handed down the rendering chain and reused whenever possible. Reaching node 5, a connection from node 4 will be detected. Now comes the tricky part: as node 4 comes after node 5 in the OrderedNodes, there is no buffer yet that’s associated with node 4. Consequently, the function getBufferContaining(…) returns -1 and a feedback loop is assumed. So far, so good, but then buffer 5 gets handed the above-mentioned getReadOnlyEmptyBuffer. In the end, no sound is being handed down to the output node nr. 3.
When you interchange the order of 4 and 5 in the chain, the “normal” part of the sound goes through but the feedback loop has no effect, again because of the empty buffer that is being used in it.
So to conclude: a network with a feedback loop behaves differently when the order of creation of the network nodes is changed. In any case, the feedback loop does not work as expected. Jules, is there any chance that you might remember what you wanted to achieve with these empty buffers? It seems to me that one should run through the rendering sequence twice in order to get the buffer id’s of nodes further down the chain that are feeded back into the network correct. Sorry for the long post, but it’s really a complex subject (at least to me…). Any help would be very much appreciated!
It is a complex subject, but I’m afraid I’ve no time this week to spend digging through it! Remind me again soon and I’ll try to find a spare hour to figure it out!
Sorry, have been up to my ears in work, and this sounds like it’d require a couple of hours that I can’t find right now…!