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
