[Csnd] Internals question on krate and events for analogue env emulation

[Csnd] Internals question on krate and events for analogue env emulation

Date	2021-05-21 16:49
From	Iain Duncan
Subject	[Csnd] Internals question on krate and events for analogue env emulation
	Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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

Date	2021-05-22 18:32
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] Internals question on krate and events for analogue env emulation
	A couple of things: the lowest order instrument is 1. Instrument 0 is any code outside instruments (that is, global). But that only has an i-pass. Instruments are executed in ascending order, so any global resource set in a lower order instrument can be accessed in a higher order instrument. Score events are ksmps-quantised, but if you use --sample-accurate, offsets are applied to make the sound start at the requested time. Prof. Victor Lazzarini Maynooth University Ireland On May 21, 2021, at 4:49 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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

Date	2021-05-22 21:45
From	Iain Duncan
Subject	Re: [Csnd] [EXTERNAL] [Csnd] Internals question on krate and events for analogue env emulation
	Thanks Victor, much appreciated. Couple of further questions inline On Sat, May 22, 2021 at 10:32 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: A couple of things: the lowest order instrument is 1. Instrument 0 is any code outside instruments (that is, global). But that only has an i-pass. Instruments are executed in ascending order, so any global resource set in a lower order instrument can be accessed in a higher order instrument. Is there a way to control order for named instruments too, or is it just better to stick to numbers if order is important? Score events are ksmps-quantised, but if you use --sample-accurate, offsets are applied to make the sound start at the requested time. Ah, ok, that explains it. I remembered testing and seeing that onset time was sub-ksmp accurate and so wondered if ksmps processing was interleaved or something. So is the adjustment for sample accurate time done after the ksmp is rendered? (ie, vector is filled, and then the whole biz is delayed). And presumably for this to work, shifting must either be only delays or there must be some latency sufficient to allow advances? Finally, is this kind of internal stuff covered in your book of 2016? Have been pondering getting it to get up on changes in the last 10 years. thanks for answering! iain Prof. Victor Lazzarini Maynooth University Ireland On May 21, 2021, at 4:49 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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

Date	2021-05-22 23:16
From	Victor Lazzarini
Subject	Re: [Csnd] [EXTERNAL] [Csnd] Internals question on krate and events for analogue env emulation
	Prof. Victor Lazzarini Maynooth University Ireland On May 22, 2021, at 9:45 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Thanks Victor, much appreciated. Couple of further questions inline On Sat, May 22, 2021 at 10:32 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: A couple of things: the lowest order instrument is 1. Instrument 0 is any code outside instruments (that is, global). But that only has an i-pass. Instruments are executed in ascending order, so any global resource set in a lower order instrument can be accessed in a higher order instrument. Is there a way to control order for named instruments too, or is it just better to stick to numbers if order is important? Off the top of my head, number allocation for named instruments is given in the order the instruments are parsed and compiled (top to bottom in the orchestra). Myself, I find named instruments an unnecessary complication. Score events are ksmps-quantised, but if you use --sample-accurate, offsets are applied to make the sound start at the requested time. Ah, ok, that explains it. I remembered testing and seeing that onset time was sub-ksmp accurate and so wondered if ksmps processing was interleaved or something. So is the adjustment for sample accurate time done after the ksmp is rendered? (ie, vector is filled, and then the whole biz is delayed). And presumably for this to work, shifting must either be only delays or there must be some latency sufficient to allow advances? you need to give the --sample-accurate option (it's not set by default). There are two parts to the mechanism. First, the start time is quantised to start always at a ksmps block boundary no higher than the requested start time. Then the synthesis is given an offset so that the beginning of the block is filled with zeros. Also if the sound duration is not a full set of ksmps blocks, the end is early and the final portion of the block is zeroed. Finally, is this kind of internal stuff covered in your book of 2016? Have been pondering getting it to get up on changes in the last 10 years. yes, the book covers these things. thanks for answering! iain Prof. Victor Lazzarini Maynooth University Ireland On May 21, 2021, at 4:49 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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

Date	2021-05-22 23:22
From	Dave Seidel
Subject	Re: [Csnd] [EXTERNAL] [Csnd] Internals question on krate and events for analogue env emulation
	From the Named Instruments section of the manual -- the "+" prefix can be helpful (I've used it): For all instrument names, a number is automatically assigned (note: if the message level (-m) is not zero, these numbers are printed to the console during orchestra compilation), following these rules: any unused instrument numbers are taken up in ascending order, starting from 1 the numbers are assigned in the order of instrument name definition, so named instruments that are defined later will always have a higher number (except if the '+' modifier is used) if the instrument name was prefixed with '+', the assigned number will be higher than that of any of the (both numbered and named) other instruments without '+'. If there are multiple '+' instruments, the numbering of these will follow the order of definition, according to the above rule. Using '+' is mainly useful for global output or effect instruments, that must be performed after the other instruments. On Sat, May 22, 2021 at 6:16 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: Prof. Victor Lazzarini Maynooth University Ireland On May 22, 2021, at 9:45 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Thanks Victor, much appreciated. Couple of further questions inline On Sat, May 22, 2021 at 10:32 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: A couple of things: the lowest order instrument is 1. Instrument 0 is any code outside instruments (that is, global). But that only has an i-pass. Instruments are executed in ascending order, so any global resource set in a lower order instrument can be accessed in a higher order instrument. Is there a way to control order for named instruments too, or is it just better to stick to numbers if order is important? Off the top of my head, number allocation for named instruments is given in the order the instruments are parsed and compiled (top to bottom in the orchestra). Myself, I find named instruments an unnecessary complication. Score events are ksmps-quantised, but if you use --sample-accurate, offsets are applied to make the sound start at the requested time. Ah, ok, that explains it. I remembered testing and seeing that onset time was sub-ksmp accurate and so wondered if ksmps processing was interleaved or something. So is the adjustment for sample accurate time done after the ksmp is rendered? (ie, vector is filled, and then the whole biz is delayed). And presumably for this to work, shifting must either be only delays or there must be some latency sufficient to allow advances? you need to give the --sample-accurate option (it's not set by default). There are two parts to the mechanism. First, the start time is quantised to start always at a ksmps block boundary no higher than the requested start time. Then the synthesis is given an offset so that the beginning of the block is filled with zeros. Also if the sound duration is not a full set of ksmps blocks, the end is early and the final portion of the block is zeroed. Finally, is this kind of internal stuff covered in your book of 2016? Have been pondering getting it to get up on changes in the last 10 years. yes, the book covers these things. thanks for answering! iain Prof. Victor Lazzarini Maynooth University Ireland On May 21, 2021, at 4:49 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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

Date	2021-05-22 23:45
From	Iain Duncan
Subject	Re: [Csnd] [EXTERNAL] [Csnd] Internals question on krate and events for analogue env emulation
	thanks Victor and David, I guess I should order the new book! Not easy to get here in Canada though.. take care iain On Sat, May 22, 2021 at 3:23 PM Dave Seidel <dave.seidel@gmail.com> wrote: From the Named Instruments section of the manual -- the "+" prefix can be helpful (I've used it): For all instrument names, a number is automatically assigned (note: if the message level (-m) is not zero, these numbers are printed to the console during orchestra compilation), following these rules: any unused instrument numbers are taken up in ascending order, starting from 1 the numbers are assigned in the order of instrument name definition, so named instruments that are defined later will always have a higher number (except if the '+' modifier is used) if the instrument name was prefixed with '+', the assigned number will be higher than that of any of the (both numbered and named) other instruments without '+'. If there are multiple '+' instruments, the numbering of these will follow the order of definition, according to the above rule. Using '+' is mainly useful for global output or effect instruments, that must be performed after the other instruments. On Sat, May 22, 2021 at 6:16 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: Prof. Victor Lazzarini Maynooth University Ireland On May 22, 2021, at 9:45 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Thanks Victor, much appreciated. Couple of further questions inline On Sat, May 22, 2021 at 10:32 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote: A couple of things: the lowest order instrument is 1. Instrument 0 is any code outside instruments (that is, global). But that only has an i-pass. Instruments are executed in ascending order, so any global resource set in a lower order instrument can be accessed in a higher order instrument. Is there a way to control order for named instruments too, or is it just better to stick to numbers if order is important? Off the top of my head, number allocation for named instruments is given in the order the instruments are parsed and compiled (top to bottom in the orchestra). Myself, I find named instruments an unnecessary complication. Score events are ksmps-quantised, but if you use --sample-accurate, offsets are applied to make the sound start at the requested time. Ah, ok, that explains it. I remembered testing and seeing that onset time was sub-ksmp accurate and so wondered if ksmps processing was interleaved or something. So is the adjustment for sample accurate time done after the ksmp is rendered? (ie, vector is filled, and then the whole biz is delayed). And presumably for this to work, shifting must either be only delays or there must be some latency sufficient to allow advances? you need to give the --sample-accurate option (it's not set by default). There are two parts to the mechanism. First, the start time is quantised to start always at a ksmps block boundary no higher than the requested start time. Then the synthesis is given an offset so that the beginning of the block is filled with zeros. Also if the sound duration is not a full set of ksmps blocks, the end is early and the final portion of the block is zeroed. Finally, is this kind of internal stuff covered in your book of 2016? Have been pondering getting it to get up on changes in the last 10 years. yes, the book covers these things. thanks for answering! iain Prof. Victor Lazzarini Maynooth University Ireland On May 21, 2021, at 4:49 PM, Iain Duncan <iainduncanlists@gmail.com> wrote: Warning This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe. Hi folks, I'm trying to make modular-synth helpers with the csound~ object in max, and have a question that I realized I don't think i ever properly knew the answer to back when I csounded a decade ago.. hopefully I can explain this ok. Question, is it the case that: On an "i" event, after the i-pass, the next thing that happens is always the next kpass, which is global. So that if a dispatching instrument numbered 0 set a k-channel (for a gate say) it is guaranteed that higher number instruments will have a chance to listen to this channel, in the order of their instrument numbers, and there is no chance of them "missing" a single k-pass cycle gate. And if the kpass is global, I think if I understand correctly, this also means audio generation of any instrument is actually quantized to the next kpass time, even if the i-event is triggered between kpasses? As in, audio event onset will be jittered off it's "correct" time by a kpass of time, with the overall temporal accuracy correct in the long term but potentially up to ksps latent. I believe this is what happens in Max if "audio in interrupt" is on: long term scheduling stays accurate, but short term scheduling is quantized to the size of the signal vector because the scheduler runs one queue consumption pass per signal vector. I am hoping I can have a controller instrument triggered by i statements, and have it pulse a gate channel that another instrument is listening to, with that instrument drawing the envelope line, and being smart about "picking up where it left off" (like many analogue envelopes do), without the env instrument having to have too much reinit and tie sorting out in there. thanks! 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