You are correct. There is one thing though, you would have to make
sure that your jack-in and jack-out operations are performed on ksmps
boundaries, and possibly with some kind of de-clicking envelop over
them. This is perhaps an ingenious idea. We have so much memory you
could have quite a bit of stuff sitting around waiting to run. I think
Csound will traverse the lists of instruments and skip inactive ones
though, so there is some overhead in that.

Regards,
Mike

On Tue, Mar 8, 2011 at 7:10 PM, thorin kerr  wrote:
> Hi Csounders.
> I've been thinking about patching instruments in real time (i.e. Max/MSP,
> PD, Buzz..-style), ... and I just want to make sure I don't go down the
> wrong road with this...
> If I use Zak or Mixer opcodes for patching, I could - in theory - change a
> patch in real time (i.e. have a source instrument send to a chorus
> instrument, then later send to a reverb instrument).
> But... the limitation in Csound is that my signal chain needs to use
> instrument numbers in ascending order. (i.e. I can't connect Instrument 10
> to instrument 9) Is this correct?
> However, an instrument can be given multiple instrument numbers (i.e. I can
> use "instr 10, 20, 30. 40" ). So... as long as I keep track of  the
> instrument numbers in the chain, I could decide to patch to an instrument
> already running (if the destination instrument already has a higher
> instrument number than the source), or start a new instance of the
> instrument with a higher instrument number than the source, and then patch
> to that instrument.
> So my question is - if this makes sense - do any of you see potential
> problems with this? Have I missed something?
> cheers
> Thorin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Mar 9, 2011 at 12:17 AM, Michael Gogins 
> wrote:
>>
>> Another approach to consider is pure Csound orchestra code and would
>> work like this:
>>
>> (1) Define your "modules" as user-defined opcodes in one or more include
>> files.
>>
>> (2) Patch your "modules" together in named instruments, these are your
>> "patches." Named instruments can also be "effects" for processing
>> signals. Each instrument and effect can go into its own file. Use
>> ftgenonce in the body of the instr definition to keep the function
>> tables together with the instruments. Use the signal flow opcodes to
>> define inlets and outlets for your instruments and effects. Not
>> channels.
>>
>> (3) In your high-level, user orchestra (the "arrange page" of your
>> synth, if you will) include your UDO file first, then your patch
>> files, then wire your patches together using the signal flow opcodes.
>> Not channels.
>>
>> This is the approach I myself use, although I haven't created as many
>> "modules" as you probably would like to do. BTW, you might be able to
>> borrow a lot of the ones already defined in Cabel for use in your own
>> system.
>>
>> Regards,
>> Mike
>>
>> On Tue, Mar 8, 2011 at 9:02 AM, Joseph Sanger  wrote:
>> > Hi there, thanks for the advice - I did look at Cabel, but only on a
>> > surface
>> > level, I have no idea what is going on behind the GUI really. I've
>> > actually
>> > been very happy with the way everything has been going up until this
>> > point,
>> > using csound macros, but if they (or my use/abuse of them) continue to
>> > cause
>> > me problems I'll certainly look at some other approaches.
>> >
>> > Yours,
>> >
>> > Joe
>> >
>> > On 08/03/11 22:43, Michael Gogins wrote:
>> >>
>> >> Another question about your project, did you look at Cabel or consider
>> >> the same approach, i.e. using a scripting language such as Python or
>> >> Lua to define modules that would then generate Csound code? Such an
>> >> approach would be much easier to write, understand, and debug. I think
>> >> athenaCL also has a templating approach to generating Csound
>> >> orchestras.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger
>> >>  wrote:
>> >>>
>> >>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>> >>>>>
>> >>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway,
>> >>>>> to
>> >>>>> avoid using macros. I still wonder if it might be a bug with the
>> >>>>> macro
>> >>>>> system, I know all the bits of my code work in smaller chunks. The
>> >>>>> trouble is that it would take quite a long time to de-macro
>> >>>>> everything
>> >>>>> manually and make a (long) test csd.
>> >>>>>
>> >>>>> Thanks again,
>> >>>>>
>> >>>>> Joe
>> >>>>>
>> >>>>> On 08/03/11 20:03, Michael Gogins wrote:
>> >>>>
>> >>>> There have been a number of changes in macros, but mainly related to
>> >>>> the
>> >>>> new parser.  The strace is rather too low-level.  We see the read cal
>> >>>> which is from freas or scanf etc, and we are not seeing the chapter3
>> >>>> functions.  Running under gdb and getting the backtrace is usually a
>> >>>> better method.  If you are willing to send me the inputs (on
>> >>>> jpff@codemist.co.uk) I will try here on my development and
>> >>>> debug-enabled
>> >>>> system.  At presentr I do not feel I have enough information to
>> >>>> comment
>> >>>>
>> >>>> ==John ff
>> >>>>
>> >>>>
>> >>>>
>> >>>> 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"
>> >>>>
>> >>> Many thanks for offering to help. When you say the "inputs" do you
>> >>> mean
>> >>> the
>> >>> .csds and the macro .orcs? I can get them together, but it won't make
>> >>> a
>> >>> sound without the host app - I'd rather not send that yet as it's
>> >>> quite
>> >>> early stages! - but the host app sends all of the score events and
>> >>> chnget/chnset stuff to the csound section. Anyway the problem happens
>> >>> before
>> >>> that. I'm at work now, I'll do it when I get home.
>> >>>
>> >>> Thanks again,
>> >>>
>> >>> Joe
>> >>>
>> >>> PS do people using this list usually prefer bottom-posting for
>> >>> answering
>> >>> mails?
>> >>>
>> >>> --
>> >>> Joseph Sanger
>> >>> Blueberry Eikaiwa
>> >>> www.bbeikaiwa.com
>> >>>
>> >>>
>> >>>
>> >>> 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"
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Joseph Sanger
>> > Blueberry Eikaiwa
>> > www.bbeikaiwa.com
>> >
>> >
>> >
>> > 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"
>> >
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> 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"
>>
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


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"

I don't think they use more than a little more memory.

You can repatch as many connections at a time as you like, as long as
you do it between kperiods. In practice, this means you can do it at
i-rate or k-rate. I didn't even really need to mention this...

Regards,
Mike

On Tue, Mar 8, 2011 at 8:26 PM, thorin kerr  wrote:
> ksmps boundaries....  Not sure what you mean. Do you mean I should only
> change a single connection per ksmps block? (and wait for the next ksmps
> block for the next connection)
> My thought was to use a 'patching instrument', which would update the signal
> chain (probably just updating an Ftable). I understand instrument events
> used to be quantised to the control rate... but that's not the case anymore?
> Do multiple instruments with multiple instrument numbers use more memory?
> Thorin
>
> On Wed, Mar 9, 2011 at 11:09 AM, Michael Gogins 
> wrote:
>>
>> You are correct. There is one thing though, you would have to make
>> sure that your jack-in and jack-out operations are performed on ksmps
>> boundaries, and possibly with some kind of de-clicking envelop over
>> them. This is perhaps an ingenious idea. We have so much memory you
>> could have quite a bit of stuff sitting around waiting to run. I think
>> Csound will traverse the lists of instruments and skip inactive ones
>> though, so there is some overhead in that.
>>
>> Regards,
>> Mike
>>
>> On Tue, Mar 8, 2011 at 7:10 PM, thorin kerr  wrote:
>> > Hi Csounders.
>> > I've been thinking about patching instruments in real time (i.e.
>> > Max/MSP,
>> > PD, Buzz..-style), ... and I just want to make sure I don't go down the
>> > wrong road with this...
>> > If I use Zak or Mixer opcodes for patching, I could - in theory - change
>> > a
>> > patch in real time (i.e. have a source instrument send to a chorus
>> > instrument, then later send to a reverb instrument).
>> > But... the limitation in Csound is that my signal chain needs to use
>> > instrument numbers in ascending order. (i.e. I can't connect Instrument
>> > 10
>> > to instrument 9) Is this correct?
>> > However, an instrument can be given multiple instrument numbers (i.e. I
>> > can
>> > use "instr 10, 20, 30. 40" ). So... as long as I keep track of  the
>> > instrument numbers in the chain, I could decide to patch to an
>> > instrument
>> > already running (if the destination instrument already has a higher
>> > instrument number than the source), or start a new instance of the
>> > instrument with a higher instrument number than the source, and then
>> > patch
>> > to that instrument.
>> > So my question is - if this makes sense - do any of you see potential
>> > problems with this? Have I missed something?
>> > cheers
>> > Thorin
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Mar 9, 2011 at 12:17 AM, Michael Gogins
>> > 
>> > wrote:
>> >>
>> >> Another approach to consider is pure Csound orchestra code and would
>> >> work like this:
>> >>
>> >> (1) Define your "modules" as user-defined opcodes in one or more
>> >> include
>> >> files.
>> >>
>> >> (2) Patch your "modules" together in named instruments, these are your
>> >> "patches." Named instruments can also be "effects" for processing
>> >> signals. Each instrument and effect can go into its own file. Use
>> >> ftgenonce in the body of the instr definition to keep the function
>> >> tables together with the instruments. Use the signal flow opcodes to
>> >> define inlets and outlets for your instruments and effects. Not
>> >> channels.
>> >>
>> >> (3) In your high-level, user orchestra (the "arrange page" of your
>> >> synth, if you will) include your UDO file first, then your patch
>> >> files, then wire your patches together using the signal flow opcodes.
>> >> Not channels.
>> >>
>> >> This is the approach I myself use, although I haven't created as many
>> >> "modules" as you probably would like to do. BTW, you might be able to
>> >> borrow a lot of the ones already defined in Cabel for use in your own
>> >> system.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Tue, Mar 8, 2011 at 9:02 AM, Joseph Sanger 
>> >> wrote:
>> >> > Hi there, thanks for the advice - I did look at Cabel, but only on a
>> >> > surface
>> >> > level, I have no idea what is going on behind the GUI really. I've
>> >> > actually
>> >> > been very happy with the way everything has been going up until this
>> >> > point,
>> >> > using csound macros, but if they (or my use/abuse of them) continue
>> >> > to
>> >> > cause
>> >> > me problems I'll certainly look at some other approaches.
>> >> >
>> >> > Yours,
>> >> >
>> >> > Joe
>> >> >
>> >> > On 08/03/11 22:43, Michael Gogins wrote:
>> >> >>
>> >> >> Another question about your project, did you look at Cabel or
>> >> >> consider
>> >> >> the same approach, i.e. using a scripting language such as Python or
>> >> >> Lua to define modules that would then generate Csound code? Such an
>> >> >> approach would be much easier to write, understand, and debug. I
>> >> >> think
>> >> >> athenaCL also has a templating approach to generating Csound
>> >> >> orchestras.
>> >> >>
>> >> >> Regards,
>> >> >> Mike
>> >> >>
>> >> >> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger
>> >> >>  wrote:
>> >> >>>
>> >> >>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>> >> >>>>>
>> >> >>>>> OK, thanks for the advice - so perhaps I should rewrite it
>> >> >>>>> anyway,
>> >> >>>>> to
>> >> >>>>> avoid using macros. I still wonder if it might be a bug with the
>> >> >>>>> macro
>> >> >>>>> system, I know all the bits of my code work in smaller chunks.
>> >> >>>>> The
>> >> >>>>> trouble is that it would take quite a long time to de-macro
>> >> >>>>> everything
>> >> >>>>> manually and make a (long) test csd.
>> >> >>>>>
>> >> >>>>> Thanks again,
>> >> >>>>>
>> >> >>>>> Joe
>> >> >>>>>
>> >> >>>>> On 08/03/11 20:03, Michael Gogins wrote:
>> >> >>>>
>> >> >>>> There have been a number of changes in macros, but mainly related
>> >> >>>> to
>> >> >>>> the
>> >> >>>> new parser.  The strace is rather too low-level.  We see the read
>> >> >>>> cal
>> >> >>>> which is from freas or scanf etc, and we are not seeing the
>> >> >>>> chapter3
>> >> >>>> functions.  Running under gdb and getting the backtrace is usually
>> >> >>>> a
>> >> >>>> better method.  If you are willing to send me the inputs (on
>> >> >>>> jpff@codemist.co.uk) I will try here on my development and
>> >> >>>> debug-enabled
>> >> >>>> system.  At presentr I do not feel I have enough information to
>> >> >>>> comment
>> >> >>>>
>> >> >>>> ==John ff
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> 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"
>> >> >>>>
>> >> >>> Many thanks for offering to help. When you say the "inputs" do you
>> >> >>> mean
>> >> >>> the
>> >> >>> .csds and the macro .orcs? I can get them together, but it won't
>> >> >>> make
>> >> >>> a
>> >> >>> sound without the host app - I'd rather not send that yet as it's
>> >> >>> quite
>> >> >>> early stages! - but the host app sends all of the score events and
>> >> >>> chnget/chnset stuff to the csound section. Anyway the problem
>> >> >>> happens
>> >> >>> before
>> >> >>> that. I'm at work now, I'll do it when I get home.
>> >> >>>
>> >> >>> Thanks again,
>> >> >>>
>> >> >>> Joe
>> >> >>>
>> >> >>> PS do people using this list usually prefer bottom-posting for
>> >> >>> answering
>> >> >>> mails?
>> >> >>>
>> >> >>> --
>> >> >>> Joseph Sanger
>> >> >>> Blueberry Eikaiwa
>> >> >>> www.bbeikaiwa.com
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> 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"
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Joseph Sanger
>> >> > Blueberry Eikaiwa
>> >> > www.bbeikaiwa.com
>> >> >
>> >> >
>> >> >
>> >> > 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"
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://www.michael-gogins.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> 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"
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> 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"
>>
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


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"