Thanks, Julius. I'm afraid that that wouldn't help. The output section is just blocking the four duplicated signals and is merging the remaining four when running with two or one channels. After the feedback section, there are the "input", "matrix" and "delay" sections and I'd need to know what happens before them.
Defining those sections was for me an attempt to simplify the process function to easily route any node to the output while not having to change too much in the process but that's not how it was. In a feedforward configuration setting intermediate functions is usually what I do but this one is a self-oscillating system and I can't break the loops for inspection. Thanks, Dario <http://dariosanfilippo.tumblr.com> On Sun, 3 Feb 2019 at 17:32, Julius Smith <j...@ccrma.stanford.edu> wrote: > Hi Dario, > > How about just letting everything go to the output? E.g., > > //output(n) = si.bus(order*2) :> si.bus(channels); > output(n) = si.bus(order*2); > > I often route whatever I want to see to the output so I can take a > look in Octave. > > Another good practice is to define several intermediate functions, and > set process to them individually for testing purposes. This also > makes the block diagram more hierarchical. > > - Julius > > On Sun, Feb 3, 2019 at 10:12 AM Dario Sanfilippo > <sanfilippo.da...@gmail.com> wrote: > > > > Hi, Urban. > > > > On Fri, 1 Feb 2019 at 16:48, <ur...@gmx.de> wrote: > >> > >> As I understand, routing is the problem here. It can be done; but you > have to rewrite the feedback loop - which scrambles your code. I have a > nested allpass somewhere with an output tap from the inner loop. Is that > what you mean? > > > > > > Your allpass example could be helpful, are you willing to share it? > > > > This is my situation at the moment: > > > > order = 4; > > channels = 2; > > > > // SECTIONS > > > > input = si.bus(order); > > matrix = si.bus(order); > > delay(x) = si.bus(order); > > nltf = si.bus(order); > > fb = si.bus(order*2) :> si.bus(order); > > output(n) = si.bus(order*2) :> si.bus(channels); > > > > // MAIN > > > > process(x) = (input : matrix : delay(x) <: si.bus(order*2)) ~ > ((si.bus(order) :> _/(order) <: si.bus(order)) , nltf : > ro.interleave(order, 2) : fb) : output(channels); > > > > I would need to inspect the signals coming out from, for example, the > "fb" section. I believe that there must be a generalised proceedure to send > any recursive signal to the output and rewrite the process accordingly but > I haven't found it yet. I'll find a way eventually. > > > > Thanks, > > Dario > > > > > >> > >> I resorted to viewing the output of the nested structure und understand > that. Kind a complex. I sometimes write test routines containing simplified > versions of the nested structures. Pattern matching seems limited in this > regard. > >> > >> -- > >> Urban Schlemmer > >> - Diplomtonmeister -\\ > >> - Formation supérieure aux métiers du son (FSMS) -\\ > >> http://chiselapp.com/user/jcage/repository/rdk/doc/www/www/revdev.html > >> > >> > >> Gesendet: Freitag, 01. Februar 2019 um 10:42 Uhr > >> Von: "Dario Sanfilippo" <sanfilippo.da...@gmail.com> > >> An: "Faust users" <faudiostream-users@lists.sourceforge.net> > >> Betreff: [Faudiostream-users] Routing signals to output > >> Hello. > >> > >> I searched the archives and there's an email from 24/07/2017 (Debugging > "peripheral" values that are not the main signal path) but it didn't get an > answer, at least not publicly. I'm having the same problem so I'm bringing > it back. > >> > >> I have a network with several modules and nested feedback loops. I need > to inspect some of the signals which are not part of the main output to > make sure that their behaviour is correct. > >> > >> When those signals are within the feedback paths, it seems less > straightforward to route them to the output so that they can be inspected > with faust2plot. A send2output function would be great but I don't that > there's something like that. > >> > >> Do you have some procedure to send any signals to the output without > changing most parts of the process? > >> > >> Thanks, > >> Dario > >> _______________________________________________ Faudiostream-users > mailing list Faudiostream-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/faudiostream-users > > > > _______________________________________________ > > Faudiostream-users mailing list > > Faudiostream-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/faudiostream-users > > > > -- > > Julius O. Smith III <j...@ccrma.stanford.edu> > Professor of Music and, by courtesy, Electrical Engineering > CCRMA, Stanford University > http://ccrma.stanford.edu/~jos/ >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
