Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

This can be solved by giving multiple numbers to an instrument

; fx1
instr 100, 1100, 2100, 3100

endin

Then, if fx1 should be scheduled in slot 3, call it as 3100, 
if it needs to be scheduled at slot 0, call it as 100.

On 21.04.20 16:33, Syl Morrison wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

It is true that the signal flow graph opcodes do not deal with order of operations. In practice, I do not find this to be a problem. If necessary, instruments and effects code in the orchestra can be arranged in the proper order of execution.

It is also true that these opcodes do not work with multiple instances of effects, if by that you mean instrument i1 uses effect e1 with settings s1 and routes that to buss b1, while another instance of instrument i1 uses another instance of effect e1 with settings s2 and routes that to buss b2. This kind of routing was not part of the design. It is possible to work around this to some extent by defining multiple effects and instruments that contain the same or similar code. I would implement this if I could see how to do it. I would welcome constructive suggestions.

These opcodes were designed to be used as part of a system for creating modular orchestras. The main idea is to separate code for defining instruments and effects, mostly kept in #include files, from code for routing instruments and effects signals, kept in the orchestra header. This in turn makes it easy to re-use instrument definition code in different orchestras without copying and pasting.

For an example, see https://gogins.github.io/csound-extended/html/SignalFlowGraphOpcodes.html. This has a working example you can play in your browser. 

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Apr 21, 2020 at 11:12 AM Steven Yi <stevenyi@gmail.com> wrote:

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Yo thank you all for your inputs, I had NO idea you could do multiple instrument numbers on a per instrument basis, thats mad, for an always on instrument, would the best shout with this approach to be when the input source changes, turnoff the running instance and turnon the other number instance? I guess in my use case it probably makes more sense to use Michael's signal flow opcodes, as all we really need to worry about is the IO of each effect, rather than handling multiple instances, because this is working with fluidEngine, so it'll receive one buffer at a time into a single instance of each effect! Really interesting to note all this stuff though!

On Tue, Apr 21, 2020 at 4:49 PM Michael Gogins <michael.gogins@gmail.com> wrote:

It is true that the signal flow graph opcodes do not deal with order of operations. In practice, I do not find this to be a problem. If necessary, instruments and effects code in the orchestra can be arranged in the proper order of execution.

It is also true that these opcodes do not work with multiple instances of effects, if by that you mean instrument i1 uses effect e1 with settings s1 and routes that to buss b1, while another instance of instrument i1 uses another instance of effect e1 with settings s2 and routes that to buss b2. This kind of routing was not part of the design. It is possible to work around this to some extent by defining multiple effects and instruments that contain the same or similar code. I would implement this if I could see how to do it. I would welcome constructive suggestions.

These opcodes were designed to be used as part of a system for creating modular orchestras. The main idea is to separate code for defining instruments and effects, mostly kept in #include files, from code for routing instruments and effects signals, kept in the orchestra header. This in turn makes it easy to re-use instrument definition code in different orchestras without copying and pasting.

For an example, see https://gogins.github.io/csound-extended/html/SignalFlowGraphOpcodes.html. This has a working example you can play in your browser. 

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Apr 21, 2020 at 11:12 AM Steven Yi <stevenyi@gmail.com> wrote:

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Btw, there are also the extremely robust zak opcodes. I haven't used them in eons, but they never failed me.

On Tue, 21 Apr 2020 at 16:58, Syl Morrison <honoonu@gmail.com> wrote:

Yo thank you all for your inputs, I had NO idea you could do multiple instrument numbers on a per instrument basis, thats mad, for an always on instrument, would the best shout with this approach to be when the input source changes, turnoff the running instance and turnon the other number instance? I guess in my use case it probably makes more sense to use Michael's signal flow opcodes, as all we really need to worry about is the IO of each effect, rather than handling multiple instances, because this is working with fluidEngine, so it'll receive one buffer at a time into a single instance of each effect! Really interesting to note all this stuff though!

On Tue, Apr 21, 2020 at 4:49 PM Michael Gogins <michael.gogins@gmail.com> wrote:

It is true that the signal flow graph opcodes do not deal with order of operations. In practice, I do not find this to be a problem. If necessary, instruments and effects code in the orchestra can be arranged in the proper order of execution.

It is also true that these opcodes do not work with multiple instances of effects, if by that you mean instrument i1 uses effect e1 with settings s1 and routes that to buss b1, while another instance of instrument i1 uses another instance of effect e1 with settings s2 and routes that to buss b2. This kind of routing was not part of the design. It is possible to work around this to some extent by defining multiple effects and instruments that contain the same or similar code. I would implement this if I could see how to do it. I would welcome constructive suggestions.

These opcodes were designed to be used as part of a system for creating modular orchestras. The main idea is to separate code for defining instruments and effects, mostly kept in #include files, from code for routing instruments and effects signals, kept in the orchestra header. This in turn makes it easy to re-use instrument definition code in different orchestras without copying and pasting.

For an example, see https://gogins.github.io/csound-extended/html/SignalFlowGraphOpcodes.html. This has a working example you can play in your browser. 

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Apr 21, 2020 at 11:12 AM Steven Yi <stevenyi@gmail.com> wrote:

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Thanks again for everyone's input learned a LOAD from this, we ended up going with the ZAK opcodes for convenience!

On Tue, Apr 21, 2020 at 5:06 PM Rory Walsh <rorywalsh@ear.ie> wrote:

Btw, there are also the extremely robust zak opcodes. I haven't used them in eons, but they never failed me.

On Tue, 21 Apr 2020 at 16:58, Syl Morrison <honoonu@gmail.com> wrote:

Yo thank you all for your inputs, I had NO idea you could do multiple instrument numbers on a per instrument basis, thats mad, for an always on instrument, would the best shout with this approach to be when the input source changes, turnoff the running instance and turnon the other number instance? I guess in my use case it probably makes more sense to use Michael's signal flow opcodes, as all we really need to worry about is the IO of each effect, rather than handling multiple instances, because this is working with fluidEngine, so it'll receive one buffer at a time into a single instance of each effect! Really interesting to note all this stuff though!

On Tue, Apr 21, 2020 at 4:49 PM Michael Gogins <michael.gogins@gmail.com> wrote:

It is true that the signal flow graph opcodes do not deal with order of operations. In practice, I do not find this to be a problem. If necessary, instruments and effects code in the orchestra can be arranged in the proper order of execution.

It is also true that these opcodes do not work with multiple instances of effects, if by that you mean instrument i1 uses effect e1 with settings s1 and routes that to buss b1, while another instance of instrument i1 uses another instance of effect e1 with settings s2 and routes that to buss b2. This kind of routing was not part of the design. It is possible to work around this to some extent by defining multiple effects and instruments that contain the same or similar code. I would implement this if I could see how to do it. I would welcome constructive suggestions.

These opcodes were designed to be used as part of a system for creating modular orchestras. The main idea is to separate code for defining instruments and effects, mostly kept in #include files, from code for routing instruments and effects signals, kept in the orchestra header. This in turn makes it easy to re-use instrument definition code in different orchestras without copying and pasting.

For an example, see https://gogins.github.io/csound-extended/html/SignalFlowGraphOpcodes.html. This has a working example you can play in your browser. 

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Apr 21, 2020 at 11:12 AM Steven Yi <stevenyi@gmail.com> wrote:

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Good that you found a solution. Practically speaking, the zak, chn, and signal routing opcodes do pretty much the same job. The syntax and method of using them differs, which might make one more practical than the other in each use case. 

Yes, as you mention yourself, when using multiple instr numbers and you want to change the routing order (e.g. distortion first, then into pitch shift), then you would turn off one of the effects and restart it again with another instr number (letting the instrument numbers be in the order of execution in your effects chain)..

To make it all smooth you can also add a fade in and fade out for each of the effects instruments, so that you can repatch without getting glitches in the audio.

best

Oeyvind

ons. 22. apr. 2020 kl. 00:06 skrev Syl Morrison <honoonu@gmail.com>:

Thanks again for everyone's input learned a LOAD from this, we ended up going with the ZAK opcodes for convenience!

On Tue, Apr 21, 2020 at 5:06 PM Rory Walsh <rorywalsh@ear.ie> wrote:

Btw, there are also the extremely robust zak opcodes. I haven't used them in eons, but they never failed me.

On Tue, 21 Apr 2020 at 16:58, Syl Morrison <honoonu@gmail.com> wrote:

Yo thank you all for your inputs, I had NO idea you could do multiple instrument numbers on a per instrument basis, thats mad, for an always on instrument, would the best shout with this approach to be when the input source changes, turnoff the running instance and turnon the other number instance? I guess in my use case it probably makes more sense to use Michael's signal flow opcodes, as all we really need to worry about is the IO of each effect, rather than handling multiple instances, because this is working with fluidEngine, so it'll receive one buffer at a time into a single instance of each effect! Really interesting to note all this stuff though!

On Tue, Apr 21, 2020 at 4:49 PM Michael Gogins <michael.gogins@gmail.com> wrote:

It is true that the signal flow graph opcodes do not deal with order of operations. In practice, I do not find this to be a problem. If necessary, instruments and effects code in the orchestra can be arranged in the proper order of execution.

It is also true that these opcodes do not work with multiple instances of effects, if by that you mean instrument i1 uses effect e1 with settings s1 and routes that to buss b1, while another instance of instrument i1 uses another instance of effect e1 with settings s2 and routes that to buss b2. This kind of routing was not part of the design. It is possible to work around this to some extent by defining multiple effects and instruments that contain the same or similar code. I would implement this if I could see how to do it. I would welcome constructive suggestions.

These opcodes were designed to be used as part of a system for creating modular orchestras. The main idea is to separate code for defining instruments and effects, mostly kept in #include files, from code for routing instruments and effects signals, kept in the orchestra header. This in turn makes it easy to re-use instrument definition code in different orchestras without copying and pasting.

For an example, see https://gogins.github.io/csound-extended/html/SignalFlowGraphOpcodes.html. This has a working example you can play in your browser. 

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Tue, Apr 21, 2020 at 11:12 AM Steven Yi <stevenyi@gmail.com> wrote:

The Signal Flow Graph opcodes don't deal with order of operations nor do they work with multiple instances of effects.

I think that maybe Oeyvind or Alex and Bernt worked out a modular system.  Might look through the archive around that.

I generally just use a single mixer instrument and code things there (or use something like Blue's mixer to handle generating it).  Instruments write out to a bus (I've used a global audio array in my live coding project) and the mixer instrument reads the instrument signals and does all mixing, sends, grouping, sidechains, etc.  Gives complete control, but I'm not sure what you're looking for in terms of modularity.

A node-based system is more suitable for something like graph topology changes at runtime, however. The UGEN proposal for CS7 was intended for this kind of runtime node connection changing and might be a nice project for this summer. It works with opcodes as individual objects that one can connect/disconnect. 

On Tue, Apr 21, 2020 at 10:44 AM Dave Seidel <dave.seidel@gmail.com> wrote:

You should definitely look into Michael Gogins' Signal Flow Graph opcodes, this is exactly the type of application they are intended for.

https://csound.com/docs/manual/SignalFlowGraphOpcodes.html  

On Tue, Apr 21, 2020 at 10:34 AM Syl Morrison <honoonu@gmail.com> wrote:

Hi all, hope you're all doing ok and coping with being on lockdown!

I'm currently trying to implement a modular fx chain, where I have an arbitrary number of fx, and I can change the order the audio passes through them. I got a version of this working using an array nfx + 1 long, where the dry signal writes to index 0, first effect to index 1 etc etc. I'm then chnsetting from the API, which tells the effect which index in the array to use as the input, and Felt really good about this, until I realised that because of the order the FX are declared, say I define 
instr PitchShift
instr Distortion
Instr Output
then Dry - PitchShift - Distortion - Output, Dry - Distortion - Output, Dry - PitchShift - Output and Dry - Output all work, BUT Dry - Distortion - PitchShift - Output doesn't, I assume because Distortion has a higher instrument number than PitchShift. So I'm wondering if there's a way I could get around this, like conceptually parallelising them, maybe using #include or something along those lines? I guess I could access the SPIN and SPOUT buffers and have seperate CSDs for each effect, but I'm kind of looking for a more elegant way, any ideas?
Cheers,

Syl

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Though Øyvind and I spent quite a few coffee cups discussing a system for this some time back, I dont think we ever got around to implement it.

Coffee you say? You sure it wasn't something a little stronger!!  

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here