[Csnd] Signal Flow Graph vs chn opcodes

[Csnd] Signal Flow Graph vs chn opcodes

Date	2011-04-24 11:40
From	joachim heintz
Subject	[Csnd] Signal Flow Graph vs chn opcodes
	Hi - I followed the discussion between Rory, Michael and others about the signal flow graph opcodes. I am wondering, what is the benefit in using them instead of the chn opcodes? I use the chnset/chnget opcodes for sending any kind of signal between instruments, and I like the flexibility because I can use strings as names. For instance, this filter chain generates two instances of instr 2 at the first call, and four instances at the second call, and sends the audio signals using the strings "filter_0", ..., "filter_N" for the N instances: -odac instr 1; master inum = p4 ;number of filters asig rand 0dbfs/20 chnset asig, "filter_0" event_i "i", 2, 0, p3, 1, inum endin instr 2; filter instnc = p4 ;instance number prints " instr 2, instance %d called%n", instnc imaxnum = p5 ;desired number of filters Sinchn sprintf "filter_%d", instnc-1 ain chnget Sinchn afilt butbp ain, 1000, 200 aout balance afilt, ain Soutchn sprintf "filter_%d", instnc chnset aout, Soutchn ;call next instance of instr 2, or instr 3 if this is the last instance if instnc < imaxnum then event_i "i", 2, 0, p3, instnc+1, imaxnum else event_i "i", 3, 0, p3, imaxnum endif endin instr 3; collect Sinchn sprintf "filter_%d", p4 ain chnget Sinchn out ain endin i 1 0 3 2 ;2 filters in a chain i 1 4 3 4 ;4 i 1 8 3 6 ;6 Would this also be possible with the signal flow graph opcodes? Or even better? Thanks for any comparision because of your experiences - joachim Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 11:50
From	peiman khosravi
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	I've never looked at these opcode but was wondering if it is possible to send pvs signals? Best, Peiman On 24/04/2011 11:40, joachim heintz wrote: > Hi - > > I followed the discussion between Rory, Michael and others about the > signal flow graph opcodes. I am wondering, what is the benefit in using > them instead of the chn opcodes? I use the chnset/chnget opcodes for > sending any kind of signal between instruments, and I like the > flexibility because I can use strings as names. For instance, this > filter chain generates two instances of instr 2 at the first call, and > four instances at the second call, and sends the audio signals using the > strings "filter_0", ..., "filter_N" for the N instances: > > > > -odac > > > > instr 1; master > inum = p4 ;number of filters > asig rand 0dbfs/20 > chnset asig, "filter_0" > event_i "i", 2, 0, p3, 1, inum > endin > > instr 2; filter > instnc = p4 ;instance number > prints " instr 2, instance %d called%n", instnc > imaxnum = p5 ;desired number of filters > Sinchn sprintf "filter_%d", instnc-1 > ain chnget Sinchn > afilt butbp ain, 1000, 200 > aout balance afilt, ain > Soutchn sprintf "filter_%d", instnc > chnset aout, Soutchn > ;call next instance of instr 2, or instr 3 if this is the last instance > if instnc< imaxnum then > event_i "i", 2, 0, p3, instnc+1, imaxnum > else > event_i "i", 3, 0, p3, imaxnum > endif > endin > > instr 3; collect > Sinchn sprintf "filter_%d", p4 > ain chnget Sinchn > out ain > endin > > > > i 1 0 3 2 ;2 filters in a chain > i 1 4 3 4 ;4 > i 1 8 3 6 ;6 > > > > Would this also be possible with the signal flow graph opcodes? Or even > better? > Thanks for any comparision because of your experiences - > > joachim > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 14:47
From	Rory Walsh
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	I tried to "signal graph"-ify your example without success (that's not to say it can't be done, I didn't spend long at it! ). The code is pasted below. I have used the channel opcodes in the past and they work fine and allow you to do interesting things as exemplified by your example. My own personal reason for not using them more often is that I prefer to reserve the use of channel opcodes in my code for communication with my hosts. Most of my instruments use a host and it's easy for me to keep track of things if I reserve the use of channel opcodes for this purpose only. If I was to start littering my code with channel opcodes for writing data internally between instruments it would clutter things up. The other thing I like about the signal graph tools is the ability to patch instruments together in one's header section. I find it a lot easier to read than scanning instruments for outputs and inputs. Rory. -odac ; Connect up the instruments to create a signal flow graph. connect "MASTER", "out", "FILTER", "in" connect "FILTER", "out", "COLLECT", "in" instr MASTER inum = p4 ;number of filters asig rand 0dbfs/20 outleta "out", asig SInstrName = "FILTER" event_i "i", SInstrName, 0, p3, 1, inum endin instr FILTER instnc = p4 ;instance number prints " instr 2, instance %d called%n", instnc imaxnum = p5 ;desired number of filters Sinchn sprintf "filter_%d", instnc-1 ain inleta "in" afilt butbp ain, 1000, 200 aout balance afilt, ain outleta "out", aout SCollect = "COLLECT" SFilter= "FILTER" ;call next instance of instr 2, or instr 3 if this is the last instance if instnc < imaxnum then event_i "i", SFilter, 0, p3, instnc+1, imaxnum else event_i "i", SCollect, 0, p3, imaxnum endif endin instr COLLECT Sinchn sprintf "filter_%d", p4 ain inleta "in" out ain endin i"MASTER" 0 3 2 ;2 filters in a chain i"MASTER" 4 3 4 ;4 i"MASTER" 8 3 6 ;6 Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 16:24
From	joachim heintz
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	Thanks for the explanation, Rory. That's good to know. Best - joachim Am 24.04.2011 15:47, schrieb Rory Walsh: > I tried to "signal graph"-ify your example without success (that's not > to say it can't be done, I didn't spend long at it! ). The code is > pasted below. I have used the channel opcodes in the past and they > work fine and allow you to do interesting things as exemplified by > your example. My own personal reason for not using them more often is > that I prefer to reserve the use of channel opcodes in my code for > communication with my hosts. Most of my instruments use a host and > it's easy for me to keep track of things if I reserve the use of > channel opcodes for this purpose only. If I was to start littering my > code with channel opcodes for writing data internally between > instruments it would clutter things up. > > The other thing I like about the signal graph tools is the ability to > patch instruments together in one's header section. I find it a lot > easier to read than scanning instruments for outputs and inputs. > > Rory. > > > > > > -odac > > > > ; Connect up the instruments to create a signal flow graph. > connect "MASTER", "out", "FILTER", "in" > connect "FILTER", "out", "COLLECT", "in" > > instr MASTER > inum = p4 ;number of filters > asig rand 0dbfs/20 > outleta "out", asig > SInstrName = "FILTER" > event_i "i", SInstrName, 0, p3, 1, inum > endin > > instr FILTER > instnc = p4 ;instance number > prints " instr 2, instance %d called%n", instnc > imaxnum = p5 ;desired number of filters > Sinchn sprintf "filter_%d", instnc-1 > ain inleta "in" > afilt butbp ain, 1000, 200 > aout balance afilt, ain > outleta "out", aout > > SCollect = "COLLECT" > SFilter= "FILTER" > ;call next instance of instr 2, or instr 3 if this is the last instance > if instnc < imaxnum then > event_i "i", SFilter, 0, p3, instnc+1, imaxnum > else > event_i "i", SCollect, 0, p3, imaxnum > endif > endin > > instr COLLECT > Sinchn sprintf "filter_%d", p4 > ain inleta "in" > out ain > endin > > > > i"MASTER" 0 3 2 ;2 filters in a chain > i"MASTER" 4 3 4 ;4 > i"MASTER" 8 3 6 ;6 > > > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 16:41
From	Steven Yi
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	Hi All, Just wanted to note that I had done an article "Emulating MIDI-based Studio Setups" that discusses mixer setups: http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html One limitation of the signal graph opcodes is being able to use an effect in multiple locations within the signal chain. Using a mixer instrument with UDO's as effects provides that flexibility if one requires it. I think in the article I ended up using the signal graph opcodes only for hooking the primary instruments, their always-on instrument code (useful for body emulations of instruments), and the mixer instrument together, then within the mixer instrument handled effects as UDO's. (This is pretty close to what blue does automatically, though blue uses global a- and k-sigs as that code was developed a long time ago (and probably could be updated)). Thanks! steven On Sun, Apr 24, 2011 at 11:24 AM, joachim heintz wrote: > Thanks for the explanation, Rory. That's good to know. Best - > joachim > > Am 24.04.2011 15:47, schrieb Rory Walsh: >> I tried to "signal graph"-ify your example without success (that's not >> to say it can't be done, I didn't spend long at it! ). The code is >> pasted below. I have used the channel opcodes in the past and they >> work fine and allow you to do interesting things as exemplified by >> your example. My own personal reason for not using them more often is >> that I prefer to reserve the use of channel opcodes in my code for >> communication with my hosts. Most of my instruments use a host and >> it's easy for me to keep track of things if I reserve the use of >> channel opcodes for this purpose only. If I was to start littering my >> code with channel opcodes for writing data internally between >> instruments it would clutter things up. >> >> The other thing I like about the signal graph tools is the ability to >> patch instruments together in one's header section. I find it a lot >> easier to read than scanning instruments for outputs and inputs. >> >> Rory. >> >> >> >> >> >> -odac >> >> >> >> ; Connect up the instruments to create a signal flow graph. >> connect "MASTER", "out", "FILTER", "in" >> connect "FILTER", "out", "COLLECT", "in" >> >> instr MASTER >> inum = p4 ;number of filters >> asig rand 0dbfs/20 >> outleta "out", asig >> SInstrName = "FILTER" >> event_i "i", SInstrName, 0, p3, 1, inum >> endin >> >> instr FILTER >> instnc = p4 ;instance number >> prints " instr 2, instance %d called%n", instnc >> imaxnum = p5 ;desired number of filters >> Sinchn sprintf "filter_%d", instnc-1 >> ain inleta "in" >> afilt butbp ain, 1000, 200 >> aout balance afilt, ain >> outleta "out", aout >> >> SCollect = "COLLECT" >> SFilter= "FILTER" >> ;call next instance of instr 2, or instr 3 if this is the last instance >> if instnc < imaxnum then >> event_i "i", SFilter, 0, p3, instnc+1, imaxnum >> else >> event_i "i", SCollect, 0, p3, imaxnum >> endif >> endin >> >> instr COLLECT >> Sinchn sprintf "filter_%d", p4 >> ain inleta "in" >> out ain >> endin >> >> >> >> i"MASTER" 0 3 2 ;2 filters in a chain >> i"MASTER" 4 3 4 ;4 >> i"MASTER" 8 3 6 ;6 >> >> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >> >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 16:47
From	Rory Walsh
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	That's a good point about using the same effect in different places along the signal chain. I never thought of that. On 24 April 2011 16:41, Steven Yi wrote: > Hi All, > > Just wanted to note that I had done an article "Emulating MIDI-based > Studio Setups" that discusses mixer setups: > > http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html > > One limitation of the signal graph opcodes is being able to use an > effect in multiple locations within the signal chain. Using a mixer > instrument with UDO's as effects provides that flexibility if one > requires it. I think in the article I ended up using the signal graph > opcodes only for hooking the primary instruments, their always-on > instrument code (useful for body emulations of instruments), and the > mixer instrument together, then within the mixer instrument handled > effects as UDO's. (This is pretty close to what blue does > automatically, though blue uses global a- and k-sigs as that code was > developed a long time ago (and probably could be updated)). > > Thanks! > steven > > On Sun, Apr 24, 2011 at 11:24 AM, joachim heintz wrote: >> Thanks for the explanation, Rory. That's good to know. Best - >> joachim >> >> Am 24.04.2011 15:47, schrieb Rory Walsh: >>> I tried to "signal graph"-ify your example without success (that's not >>> to say it can't be done, I didn't spend long at it! ). The code is >>> pasted below. I have used the channel opcodes in the past and they >>> work fine and allow you to do interesting things as exemplified by >>> your example. My own personal reason for not using them more often is >>> that I prefer to reserve the use of channel opcodes in my code for >>> communication with my hosts. Most of my instruments use a host and >>> it's easy for me to keep track of things if I reserve the use of >>> channel opcodes for this purpose only. If I was to start littering my >>> code with channel opcodes for writing data internally between >>> instruments it would clutter things up. >>> >>> The other thing I like about the signal graph tools is the ability to >>> patch instruments together in one's header section. I find it a lot >>> easier to read than scanning instruments for outputs and inputs. >>> >>> Rory. >>> >>> >>> >>> >>> >>> -odac >>> >>> >>> >>> ; Connect up the instruments to create a signal flow graph. >>> connect "MASTER", "out", "FILTER", "in" >>> connect "FILTER", "out", "COLLECT", "in" >>> >>> instr MASTER >>> inum = p4 ;number of filters >>> asig rand 0dbfs/20 >>> outleta "out", asig >>> SInstrName = "FILTER" >>> event_i "i", SInstrName, 0, p3, 1, inum >>> endin >>> >>> instr FILTER >>> instnc = p4 ;instance number >>> prints " instr 2, instance %d called%n", instnc >>> imaxnum = p5 ;desired number of filters >>> Sinchn sprintf "filter_%d", instnc-1 >>> ain inleta "in" >>> afilt butbp ain, 1000, 200 >>> aout balance afilt, ain >>> outleta "out", aout >>> >>> SCollect = "COLLECT" >>> SFilter= "FILTER" >>> ;call next instance of instr 2, or instr 3 if this is the last instance >>> if instnc < imaxnum then >>> event_i "i", SFilter, 0, p3, instnc+1, imaxnum >>> else >>> event_i "i", SCollect, 0, p3, imaxnum >>> endif >>> endin >>> >>> instr COLLECT >>> Sinchn sprintf "filter_%d", p4 >>> ain inleta "in" >>> out ain >>> endin >>> >>> >>> >>> i"MASTER" 0 3 2 ;2 filters in a chain >>> i"MASTER" 4 3 4 ;4 >>> i"MASTER" 8 3 6 ;6 >>> >>> >>> >>> >>> Send bugs reports to the Sourceforge bug tracker >>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>> Discussions of bugs and features can be posted here >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >>> >>> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" >> >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2011-04-24 18:05
From	Adam Puckett
Subject	Re: [Csnd] Signal Flow Graph vs chn opcodes
	Globals are nice but I guess in the professional world they are "considered harmful" like goto statements. I personally like the ability to break out of loops in odd places and/or use globals in creative ways that would be impractical with zak/chn/signal flow graphs. But for my serious compositions I will use more structured systems such as those. Adam On 4/24/11, Rory Walsh wrote: > That's a good point about using the same effect in different places > along the signal chain. I never thought of that. > > > On 24 April 2011 16:41, Steven Yi wrote: >> Hi All, >> >> Just wanted to note that I had done an article "Emulating MIDI-based >> Studio Setups" that discusses mixer setups: >> >> http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html >> >> One limitation of the signal graph opcodes is being able to use an >> effect in multiple locations within the signal chain. Using a mixer >> instrument with UDO's as effects provides that flexibility if one >> requires it. I think in the article I ended up using the signal graph >> opcodes only for hooking the primary instruments, their always-on >> instrument code (useful for body emulations of instruments), and the >> mixer instrument together, then within the mixer instrument handled >> effects as UDO's. (This is pretty close to what blue does >> automatically, though blue uses global a- and k-sigs as that code was >> developed a long time ago (and probably could be updated)). >> >> Thanks! >> steven >> >> On Sun, Apr 24, 2011 at 11:24 AM, joachim heintz >> wrote: >>> Thanks for the explanation, Rory. That's good to know. Best - >>> joachim >>> >>> Am 24.04.2011 15:47, schrieb Rory Walsh: >>>> I tried to "signal graph"-ify your example without success (that's not >>>> to say it can't be done, I didn't spend long at it! ). The code is >>>> pasted below. I have used the channel opcodes in the past and they >>>> work fine and allow you to do interesting things as exemplified by >>>> your example. My own personal reason for not using them more often is >>>> that I prefer to reserve the use of channel opcodes in my code for >>>> communication with my hosts. Most of my instruments use a host and >>>> it's easy for me to keep track of things if I reserve the use of >>>> channel opcodes for this purpose only. If I was to start littering my >>>> code with channel opcodes for writing data internally between >>>> instruments it would clutter things up. >>>> >>>> The other thing I like about the signal graph tools is the ability to >>>> patch instruments together in one's header section. I find it a lot >>>> easier to read than scanning instruments for outputs and inputs. >>>> >>>> Rory. >>>> >>>> >>>> >>>> >>>> >>>> -odac >>>> >>>> >>>> >>>> ; Connect up the instruments to create a signal flow graph. >>>> connect "MASTER", "out", "FILTER", "in" >>>> connect "FILTER", "out", "COLLECT", "in" >>>> >>>> instr MASTER >>>> inum = p4 ;number of filters >>>> asig rand 0dbfs/20 >>>> outleta "out", asig >>>> SInstrName = "FILTER" >>>> event_i "i", SInstrName, 0, p3, 1, inum >>>> endin >>>> >>>> instr FILTER >>>> instnc = p4 ;instance number >>>> prints " instr 2, instance %d called%n", instnc >>>> imaxnum = p5 ;desired number of filters >>>> Sinchn sprintf "filter_%d", instnc-1 >>>> ain inleta "in" >>>> afilt butbp ain, 1000, 200 >>>> aout balance afilt, ain >>>> outleta "out", aout >>>> >>>> SCollect = "COLLECT" >>>> SFilter= "FILTER" >>>> ;call next instance of instr 2, or instr 3 if this is the last instance >>>> if instnc < imaxnum then >>>> event_i "i", SFilter, 0, p3, instnc+1, imaxnum >>>> else >>>> event_i "i", SCollect, 0, p3, imaxnum >>>> endif >>>> endin >>>> >>>> instr COLLECT >>>> Sinchn sprintf "filter_%d", p4 >>>> ain inleta "in" >>>> out ain >>>> endin >>>> >>>> >>>> >>>> i"MASTER" 0 3 2 ;2 filters in a chain >>>> i"MASTER" 4 3 4 ;4 >>>> i"MASTER" 8 3 6 ;6 >>>> >>>> >>>> >>>> >>>> Send bugs reports to the Sourceforge bug tracker >>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>>> Discussions of bugs and features can be posted here >>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>>> csound" >>>> >>>> >>> >>> >>> Send bugs reports to the Sourceforge bug tracker >>> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >>> Discussions of bugs and features can be posted here >>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >>> csound" >>> >>> >> >> >> Send bugs reports to the Sourceforge bug tracker >> https://sourceforge.net/tracker/?group_id=81968&atid=564599 >> Discussions of bugs and features can be posted here >> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe >> csound" >> >> > > > Send bugs reports to the Sourceforge bug tracker > https://sourceforge.net/tracker/?group_id=81968&atid=564599 > Discussions of bugs and features can be posted here > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" > > Send bugs reports to the Sourceforge bug tracker https://sourceforge.net/tracker/?group_id=81968&atid=564599 Discussions of bugs and features can be posted here To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"