[Csnd] Local scope of tables?

[Csnd] Local scope of tables?

Date	2011-05-26 14:35
From	Louis Cohen
Subject	[Csnd] Local scope of tables?
	I'm writing an instrument that uses data stored in a few tables. I can access that data with no difficulty by using the table opcodes, such as tablekt. However, I'd like to instantiate several copies of this instrument, each using unique tables, not tables shared by other instances of the same instrument. Is there a way to define tables so that they are local to a single instance of an instrument? The closest solution I can see to this is the use of vectorial opcodes. I could essentially divide a large table into a series of smaller tables this way. But vectorial opcodes deliver the data as series of named variables. This makes it very awkward to refer to these entries via an index. Can anyone think of a way to access one or more tables using an index, where the tables are unique to each instance of an instrument? Although I prefer not to rely on a tool external to csound such as python, would that be a possible route to explore? best, Lou Cohen 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-05-26 16:18
From	peiman khosravi
Subject	Re: [Csnd] Local scope of tables?
	I guess something like this would be simpler. -odac -d sr = 96000 ksmps = 100 nchnls = 6 0dbfs = 1 instr 1 ir active 1 itable ftgen 1000+ir, 0, 4096, 20, p4 endin i1 0 10 1 i1 0 10 6 On 26/05/2011 14:35, Louis Cohen wrote: > I'm writing an instrument that uses data stored in a few tables. I can > access that data with no difficulty by using the table opcodes, such > as tablekt. > > However, I'd like to instantiate several copies of this instrument, > each using unique tables, not tables shared by other instances of the > same instrument. > > Is there a way to define tables so that they are local to a single > instance of an instrument? > > The closest solution I can see to this is the use of vectorial > opcodes. I could essentially divide a large table into a series of > smaller tables this way. > > But vectorial opcodes deliver the data as series of named variables. > This makes it very awkward to refer to these entries via an index. > > Can anyone think of a way to access one or more tables using an index, > where the tables are unique to each instance of an instrument? > > Although I prefer not to rely on a tool external to csound such as > python, would that be a possible route to explore? > > best, > Lou Cohen > > > > 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-05-26 16:28
From	peiman khosravi
Subject	Re: [Csnd] Local scope of tables?
	Actually you would want to delete the table at the end of the note. P On 26/05/2011 16:18, peiman khosravi wrote: > I guess something like this would be simpler. > > > > > > -odac -d > > > > > sr = 96000 > ksmps = 100 > nchnls = 6 > 0dbfs = 1 > > instr 1 > > ir active 1 > > itable ftgen 1000+ir, 0, 4096, 20, p4 > > endin > > > > > > i1 0 10 1 > i1 0 10 6 > > > > > > On 26/05/2011 14:35, Louis Cohen wrote: >> I'm writing an instrument that uses data stored in a few tables. I >> can access that data with no difficulty by using the table opcodes, >> such as tablekt. >> >> However, I'd like to instantiate several copies of this instrument, >> each using unique tables, not tables shared by other instances of the >> same instrument. >> >> Is there a way to define tables so that they are local to a single >> instance of an instrument? >> >> The closest solution I can see to this is the use of vectorial >> opcodes. I could essentially divide a large table into a series of >> smaller tables this way. >> >> But vectorial opcodes deliver the data as series of named variables. >> This makes it very awkward to refer to these entries via an index. >> >> Can anyone think of a way to access one or more tables using an >> index, where the tables are unique to each instance of an instrument? >> >> Although I prefer not to rely on a tool external to csound such as >> python, would that be a possible route to explore? >> >> best, >> Lou Cohen >> >> >> >> 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-05-26 16:30
From	peiman khosravi
Subject	Re: [Csnd] Local scope of tables?
	Like this: -odac -d sr = 96000 ksmps = 100 nchnls = 6 0dbfs = 1 instr 1 ir active 1 itable ftgen 1000+ir, 0, 4096, 20, p4 ftfree itable, p3 endin i1 0 2 1 i1 0 1 6 i1 3 1 3 On 26/05/2011 16:18, peiman khosravi wrote: > I guess something like this would be simpler. > > > > > > -odac -d > > > > > sr = 96000 > ksmps = 100 > nchnls = 6 > 0dbfs = 1 > > instr 1 > > ir active 1 > > itable ftgen 1000+ir, 0, 4096, 20, p4 > > endin > > > > > > i1 0 10 1 > i1 0 10 6 > > > > > > On 26/05/2011 14:35, Louis Cohen wrote: >> I'm writing an instrument that uses data stored in a few tables. I >> can access that data with no difficulty by using the table opcodes, >> such as tablekt. >> >> However, I'd like to instantiate several copies of this instrument, >> each using unique tables, not tables shared by other instances of the >> same instrument. >> >> Is there a way to define tables so that they are local to a single >> instance of an instrument? >> >> The closest solution I can see to this is the use of vectorial >> opcodes. I could essentially divide a large table into a series of >> smaller tables this way. >> >> But vectorial opcodes deliver the data as series of named variables. >> This makes it very awkward to refer to these entries via an index. >> >> Can anyone think of a way to access one or more tables using an >> index, where the tables are unique to each instance of an instrument? >> >> Although I prefer not to rely on a tool external to csound such as >> python, would that be a possible route to explore? >> >> best, >> Lou Cohen >> >> >> >> 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-05-26 16:49
From	Steven Yi
Subject	Re: [Csnd] Local scope of tables?
	Ah, but ftgentmp does the creation and deletion all in one opcode. :) On Thu, May 26, 2011 at 8:30 AM, peiman khosravi wrote: > Like this: > > > > > > -odac -d > > > > > sr = 96000 > ksmps = 100 > nchnls = 6 > 0dbfs = 1 > > instr 1 > > ir active 1 > > itable ftgen 1000+ir, 0, 4096, 20, p4 > ftfree itable, p3 > endin > > > > > > i1 0 2 1 > i1 0 1 6 > i1 3 1 3 > > > > > > > > > On 26/05/2011 16:18, peiman khosravi wrote: >> >> I guess something like this would be simpler. >> >> >> >> >> >> -odac -d >> >> >> >> >> sr = 96000 >> ksmps = 100 >> nchnls = 6 >> 0dbfs = 1 >> >> instr 1 >> >> ir active 1 >> >> itable ftgen 1000+ir, 0, 4096, 20, p4 >> >> endin >> >> >> >> >> >> i1 0 10 1 >> i1 0 10 6 >> >> >> >> >> >> On 26/05/2011 14:35, Louis Cohen wrote: >>> >>> I'm writing an instrument that uses data stored in a few tables. I can >>> access that data with no difficulty by using the table opcodes, such as >>> tablekt. >>> >>> However, I'd like to instantiate several copies of this instrument, each >>> using unique tables, not tables shared by other instances of the same >>> instrument. >>> >>> Is there a way to define tables so that they are local to a single >>> instance of an instrument? >>> >>> The closest solution I can see to this is the use of vectorial opcodes. I >>> could essentially divide a large table into a series of smaller tables this >>> way. >>> >>> But vectorial opcodes deliver the data as series of named variables. This >>> makes it very awkward to refer to these entries via an index. >>> >>> Can anyone think of a way to access one or more tables using an index, >>> where the tables are unique to each instance of an instrument? >>> >>> Although I prefer not to rely on a tool external to csound such as >>> python, would that be a possible route to explore? >>> >>> best, >>> Lou Cohen >>> >>> >>> >>> 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-05-26 16:56
From	peiman khosravi
Subject	Re: [Csnd] Local scope of tables?
	Yes indeed, thanks for pointing this out! Best, Peiman On 26/05/2011 16:49, Steven Yi wrote: > Ah, but ftgentmp does the creation and deletion all in one opcode. :) > > On Thu, May 26, 2011 at 8:30 AM, peiman khosravi > wrote: >> Like this: >> >> >> >> >> >> -odac -d >> >> >> >> >> sr = 96000 >> ksmps = 100 >> nchnls = 6 >> 0dbfs = 1 >> >> instr 1 >> >> ir active 1 >> >> itable ftgen 1000+ir, 0, 4096, 20, p4 >> ftfree itable, p3 >> endin >> >> >> >> >> >> i1 0 2 1 >> i1 0 1 6 >> i1 3 1 3 >> >> >> >> >> >> >> >> >> On 26/05/2011 16:18, peiman khosravi wrote: >>> I guess something like this would be simpler. >>> >>> >>> >>> >>> >>> -odac -d >>> >>> >>> >>> >>> sr = 96000 >>> ksmps = 100 >>> nchnls = 6 >>> 0dbfs = 1 >>> >>> instr 1 >>> >>> ir active 1 >>> >>> itable ftgen 1000+ir, 0, 4096, 20, p4 >>> >>> endin >>> >>> >>> >>> >>> >>> i1 0 10 1 >>> i1 0 10 6 >>> >>> >>> >>> >>> >>> On 26/05/2011 14:35, Louis Cohen wrote: >>>> I'm writing an instrument that uses data stored in a few tables. I can >>>> access that data with no difficulty by using the table opcodes, such as >>>> tablekt. >>>> >>>> However, I'd like to instantiate several copies of this instrument, each >>>> using unique tables, not tables shared by other instances of the same >>>> instrument. >>>> >>>> Is there a way to define tables so that they are local to a single >>>> instance of an instrument? >>>> >>>> The closest solution I can see to this is the use of vectorial opcodes. I >>>> could essentially divide a large table into a series of smaller tables this >>>> way. >>>> >>>> But vectorial opcodes deliver the data as series of named variables. This >>>> makes it very awkward to refer to these entries via an index. >>>> >>>> Can anyone think of a way to access one or more tables using an index, >>>> where the tables are unique to each instance of an instrument? >>>> >>>> Although I prefer not to rely on a tool external to csound such as >>>> python, would that be a possible route to explore? >>>> >>>> best, >>>> Lou Cohen >>>> >>>> >>>> >>>> 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-05-26 17:36
From	francesco
Subject	[Csnd] Re: Local scope of tables?
	also look at ftgenonce. "Enables the creation of function tables entirely inside instrument definitions, without any duplication of data." http://www.csounds.com/manual/html/ftgenonce.html ciao, fra -- View this message in context: http://csound.1045644.n5.nabble.com/Local-scope-of-tables-tp4428608p4429222.html Sent from the Csound - General mailing list archive at Nabble.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"

Date	2011-05-26 17:46
From	Steven Yi
Subject	Re: [Csnd] Re: Local scope of tables?
	ftgenonce doesn't seem appropriate to this situation to me, as Louis mentioned not wanting to use shared tables. ftgenonce is great for things like sine waves or other commonly used tables that can be defined in any instrument that needs it, but will only get instantiated once. One potential issue with ftgenonce (but would be with regular tables) is that if you create it, then write into it, the changes would be shared by anyone who also used the same table. It could be potentially odd if you go to load the table again later with the same params (which are used to do the caching of the table creation) would come back with the modified table. That's sort of an edge case though and could fall under the category of "user error". :P On Thu, May 26, 2011 at 9:36 AM, francesco wrote: > also look at ftgenonce. > > "Enables the creation of function tables entirely inside instrument > definitions, without any duplication of data." > > http://www.csounds.com/manual/html/ftgenonce.html > > ciao, > fra > > -- > View this message in context: http://csound.1045644.n5.nabble.com/Local-scope-of-tables-tp4428608p4429222.html > Sent from the Csound - General mailing list archive at Nabble.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" > > 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-05-26 18:20
From	Michael Gogins
Subject	Re: [Csnd] Re: Local scope of tables?
	Correct. On May 26, 2011 12:46 PM, "Steven Yi" <stevenyi@gmail.com> wrote: > ftgenonce doesn't seem appropriate to this situation to me, as Louis > mentioned not wanting to use shared tables. ftgenonce is great for > things like sine waves or other commonly used tables that can be > defined in any instrument that needs it, but will only get > instantiated once. One potential issue with ftgenonce (but would be > with regular tables) is that if you create it, then write into it, the > changes would be shared by anyone who also used the same table. It > could be potentially odd if you go to load the table again later with > the same params (which are used to do the caching of the table > creation) would come back with the modified table. That's sort of an > edge case though and could fall under the category of "user error". :P > > On Thu, May 26, 2011 at 9:36 AM, francesco <ilterzouomo@fastwebnet.it> wrote: >> also look at ftgenonce. >> >> "Enables the creation of function tables entirely inside instrument >> definitions, without any duplication of data." >> >> http://www.csounds.com/manual/html/ftgenonce.html >> >> ciao, >> fra >> >> -- >> View this message in context: http://csound.1045644.n5.nabble.com/Local-scope-of-tables-tp4428608p4429222.html >> Sent from the Csound - General mailing list archive at Nabble.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" >> >> > > > 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-05-27 02:10
From	Louis Cohen
Subject	Re: [Csnd] Local scope of tables?
	I'd like to thank everyone for all of your considered responses. I have had no time to study them, but I will be benefiting greatly from them in the next day or so. Once again, many, many thanks! =Lou On May 26, 2011, at 1:20 PM, Michael Gogins wrote: > Correct. > > On May 26, 2011 12:46 PM, "Steven Yi" wrote: > > ftgenonce doesn't seem appropriate to this situation to me, as Louis > > mentioned not wanting to use shared tables. ftgenonce is great for > > things like sine waves or other commonly used tables that can be > > defined in any instrument that needs it, but will only get > > instantiated once. One potential issue with ftgenonce (but would be > > with regular tables) is that if you create it, then write into it, > the > > changes would be shared by anyone who also used the same table. It > > could be potentially odd if you go to load the table again later > with > > the same params (which are used to do the caching of the table > > creation) would come back with the modified table. That's sort of an > > edge case though and could fall under the category of "user > error". :P > > > > On Thu, May 26, 2011 at 9:36 AM, francesco > wrote: > >> also look at ftgenonce. > >> > >> "Enables the creation of function tables entirely inside instrument > >> definitions, without any duplication of data." > >> > >> http://www.csounds.com/manual/html/ftgenonce.html > >> > >> ciao, > >> fra > >> > >> -- > >> View this message in context: http://csound.1045644.n5.nabble.com/Local-scope-of-tables-tp4428608p4429222.html > >> Sent from the Csound - General mailing list archive at Nabble.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" > >> > >> > > > > > > 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-05-27 20:21
From	Louis Cohen
Subject	Re: [Csnd] Local scope of tables?
	Peiman, Your example is elegant. However, the manual says: "Although Csound will not protest if ftgen is used inside instr-endin statements, this is not the intended or supported use, and must be handled with care as it has global effects. " Do you think I can safely ignore this warning? I could as well pre-define many tables in instr 0, as long as I was sure I knew the maximum number of active instruments. In my case the tables will be very small, probably not larger than 64 entries each. Then I just have to be sure to assign a unique table ID when I execute the "event" opcode. This could use the same mechanism you suggested. I note your additional advice that the table should be deleted at the end of the note, as in "ftfree itable, p3" And Steven's comment that ftgentmp causes the table to be deleted at the end of the instrument! Thanks. -Lou On May 26, 2011, at 11:18 AM, peiman khosravi wrote: > I guess something like this would be simpler. > > > > > > -odac -d > > > > > sr = 96000 > ksmps = 100 > nchnls = 6 > 0dbfs = 1 > > instr 1 > > ir active 1 > > itable ftgen 1000+ir, 0, 4096, 20, p4 > > endin > > > > > > i1 0 10 1 > i1 0 10 6 > > > > > > On 26/05/2011 14:35, Louis Cohen wrote: >> I'm writing an instrument that uses data stored in a few tables. I >> can access that data with no difficulty by using the table opcodes, >> such as tablekt. >> >> However, I'd like to instantiate several copies of this instrument, >> each using unique tables, not tables shared by other instances of >> the same instrument. >> >> Is there a way to define tables so that they are local to a single >> instance of an instrument? >> >> The closest solution I can see to this is the use of vectorial >> opcodes. I could essentially divide a large table into a series of >> smaller tables this way. >> >> But vectorial opcodes deliver the data as series of named >> variables. This makes it very awkward to refer to these entries via >> an index. >> >> Can anyone think of a way to access one or more tables using an >> index, where the tables are unique to each instance of an instrument? >> >> Although I prefer not to rely on a tool external to csound such as >> python, would that be a possible route to explore? >> >> best, >> Lou Cohen >> >> >> >> 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-05-27 20:21
From	Louis Cohen
Subject	Re: [Csnd] Re: Local scope of tables?
	Steven and Francesco and Michael, It does seem that separate instances of the same instrument might actually create the same shared table, since the parameters might be the same in each instance of the instrument. I suppose I could ensure different, unique, unshared tables if I could guarantee that at least one parameter value was unique at the time the ftgenonce opcode gets executed. But that seems to make the code too subtle and therefore too hard to maintain. Probably ftgenonce would be a risky choice for me, but thanks for suggestion. -Lou On May 26, 2011, at 12:46 PM, Steven Yi wrote: > ftgenonce doesn't seem appropriate to this situation to me, as Louis > mentioned not wanting to use shared tables. ftgenonce is great for > things like sine waves or other commonly used tables that can be > defined in any instrument that needs it, but will only get > instantiated once. One potential issue with ftgenonce (but would be > with regular tables) is that if you create it, then write into it, the > changes would be shared by anyone who also used the same table. It > could be potentially odd if you go to load the table again later with > the same params (which are used to do the caching of the table > creation) would come back with the modified table. That's sort of an > edge case though and could fall under the category of "user error". :P > > On Thu, May 26, 2011 at 9:36 AM, francesco > wrote: >> also look at ftgenonce. >> >> "Enables the creation of function tables entirely inside instrument >> definitions, without any duplication of data." >> >> http://www.csounds.com/manual/html/ftgenonce.html >> >> ciao, >> fra >> >> -- >> View this message in context: http://csound.1045644.n5.nabble.com/Local-scope-of-tables-tp4428608p4429222.html >> Sent from the Csound - General mailing list archive at Nabble.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" >> >> > > > 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-05-27 20:38
From	joachim heintz
Subject	Re: [Csnd] Local scope of tables?
	i never had problem creating tables from within an instrument. i think you just have take care of the numbers. i am wondering if this is also a simple solution to the local scope of a function table: setting an i-value instead of a gi-value. (this can be supplemented by an ftfree statement.) for instance: 0dbfs=1 instr 1 itab ftgen 0, 0, 1024, 10, 1 anote poscil .2, 400, itab out anote endin instr 2 itab ftgen 0, 0, 1024, 10, 1, 1, 1, 1, 1 anote poscil .2, 500, itab out anote endin i1 0 2 i2 3 2 i2 6 3 i1 6 3 best - joachim Am 27.05.2011 21:21, schrieb Louis Cohen: > Peiman, > > Your example is elegant. However, the manual says: > > "Although Csound will not protest if ftgen is used inside instr-endin > statements, this is not the intended or supported use, and must be > handled with care as it has global effects. " > > Do you think I can safely ignore this warning? > > I could as well pre-define many tables in instr 0, as long as I was sure > I knew the maximum number of active instruments. In my case the tables > will be very small, probably not larger than 64 entries each. Then I > just have to be sure to assign a unique table ID when I execute the > "event" opcode. This could use the same mechanism you suggested. > > I note your additional advice that the table should be deleted at the > end of the note, as in "ftfree itable, p3" > > And Steven's comment that ftgentmp causes the table to be deleted at the > end of the instrument! Thanks. > > -Lou > > On May 26, 2011, at 11:18 AM, peiman khosravi wrote: > >> I guess something like this would be simpler. >> >> >> >> >> >> -odac -d >> >> >> >> >> sr = 96000 >> ksmps = 100 >> nchnls = 6 >> 0dbfs = 1 >> >> instr 1 >> >> ir active 1 >> >> itable ftgen 1000+ir, 0, 4096, 20, p4 >> >> endin >> >> >> >> >> >> i1 0 10 1 >> i1 0 10 6 >> >> >> >> >> >> On 26/05/2011 14:35, Louis Cohen wrote: >>> I'm writing an instrument that uses data stored in a few tables. I >>> can access that data with no difficulty by using the table opcodes, >>> such as tablekt. >>> >>> However, I'd like to instantiate several copies of this instrument, >>> each using unique tables, not tables shared by other instances of the >>> same instrument. >>> >>> Is there a way to define tables so that they are local to a single >>> instance of an instrument? >>> >>> The closest solution I can see to this is the use of vectorial >>> opcodes. I could essentially divide a large table into a series of >>> smaller tables this way. >>> >>> But vectorial opcodes deliver the data as series of named variables. >>> This makes it very awkward to refer to these entries via an index. >>> >>> Can anyone think of a way to access one or more tables using an >>> index, where the tables are unique to each instance of an instrument? >>> >>> Although I prefer not to rely on a tool external to csound such as >>> python, would that be a possible route to explore? >>> >>> best, >>> Lou Cohen >>> >>> >>> >>> 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"