id look into the ftgen family of opcodes. but id be careful with event 
time allocation of tables if you are doing realtime stuff.

kelly


On Thu, 26 May 2011, Louis Cohen wrote:

> After posting my last note it occurred to me that an easy way to deal with my 
> problem of local tables is to write a few UDOs that access tables via two (or 
> even more) indexes.
>
> I would still appreciate learning about other techniques to handle the 
> problem of tables local to a single instance of an instrument.
>
> thanks again!
>
> -Lou
>
>
>
> 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"

After posting my last note it occurred to me that an easy way to deal  
with my problem of local tables is to write a few UDOs that access  
tables via two (or even more) indexes.

I would still appreciate learning about other techniques to handle the  
problem of tables local to a single instance of an instrument.

thanks again!

-Lou



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"

If the tables are meant to exist only while an instance of an
instrument is around, then I'd probably use ftgentmp.

On Tue, May 24, 2011 at 3:40 AM, kelly  hirai
 wrote:
> id look into the ftgen family of opcodes. but id be careful with event time
> allocation of tables if you are doing realtime stuff.
>
> kelly
>
>
> On Thu, 26 May 2011, Louis Cohen wrote:
>
>> After posting my last note it occurred to me that an easy way to deal with
>> my problem of local tables is to write a few UDOs that access tables via two
>> (or even more) indexes.
>>
>> I would still appreciate learning about other techniques to handle the
>> problem of tables local to a single instance of an instrument.
>>
>> thanks again!
>>
>> -Lou
>>
>>
>>
>> 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"

Steven,

Thanks for this idea. I had seen this opcode in the manual but  
rejected it because the example shows the table being created in instr  
1 and then referenced in instr 2. This suggests that such a table is  
not local to a single instrument.

Am I misunderstanding this?

-Lou

On May 26, 2011, at 11:25 AM, Steven Yi wrote:

> If the tables are meant to exist only while an instance of an
> instrument is around, then I'd probably use ftgentmp.
>
> On Tue, May 24, 2011 at 3:40 AM, kelly  hirai
>  wrote:
>> id look into the ftgen family of opcodes. but id be careful with  
>> event time
>> allocation of tables if you are doing realtime stuff.
>>
>> kelly
>>
>>
>> On Thu, 26 May 2011, Louis Cohen wrote:
>>
>>> After posting my last note it occurred to me that an easy way to  
>>> deal with
>>> my problem of local tables is to write a few UDOs that access  
>>> tables via two
>>> (or even more) indexes.
>>>
>>> I would still appreciate learning about other techniques to handle  
>>> the
>>> problem of tables local to a single instance of an instrument.
>>>
>>> thanks again!
>>>
>>> -Lou
>>>
>>>
>>>
>>> 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"

But nor is ftgen in the real sense. The point is, you could access the 
table globally if you wanted to but you can also choose not to.

In fact if you use ftgentmp then you can ignore my example. As this 
demonstrates:




-odac 0



sr = 44100
ksmps = 128
nchnls = 2
0dbfs = 1

instr 1
ifno  ftgentmp  0, 0, 512, 10, 1
print ifno
endin





i 1 0 10
i 1 0 10

e







You can refer to the table inside the same instrument using the name, 
rather than a number. For each instance of the instrument a new table is 
created with a different number, and the table is destroyed at the end 
of the note. The name is only accessible locally (unless of course you 
use 'gifno' instead of 'ifno'). This I believe is safe to use.

Best,

Peiman



On 27/05/2011 20:21, Louis Cohen wrote:
> Steven,
>
> Thanks for this idea. I had seen this opcode in the manual but 
> rejected it because the example shows the table being created in instr 
> 1 and then referenced in instr 2. This suggests that such a table is 
> not local to a single instrument.
>
> Am I misunderstanding this?
>
> -Lou
>
> On May 26, 2011, at 11:25 AM, Steven Yi wrote:
>
>> If the tables are meant to exist only while an instance of an
>> instrument is around, then I'd probably use ftgentmp.
>>
>> On Tue, May 24, 2011 at 3:40 AM, kelly  hirai
>>  wrote:
>>> id look into the ftgen family of opcodes. but id be careful with 
>>> event time
>>> allocation of tables if you are doing realtime stuff.
>>>
>>> kelly
>>>
>>>
>>> On Thu, 26 May 2011, Louis Cohen wrote:
>>>
>>>> After posting my last note it occurred to me that an easy way to 
>>>> deal with
>>>> my problem of local tables is to write a few UDOs that access 
>>>> tables via two
>>>> (or even more) indexes.
>>>>
>>>> I would still appreciate learning about other techniques to handle the
>>>> problem of tables local to a single instance of an instrument.
>>>>
>>>> thanks again!
>>>>
>>>> -Lou
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>         https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>> "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> "unsubscribe csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"
>



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Louis,

Your understanding is correct in that the table is not truly local,
but it is somewhat "effectively" local.  With the ftgen family of
opcodes, when 0 is used, it will look for the first available table
number and use that when creating the table, return that as the value.
For example, if you use ftgentmp locally with 0, it could say come
back with an assigned ftable number of 101.  Now, another instrument
could access that same table by using the number 101, but it'd have to
be either lucky to know that it would get assigned 101 or would have
to be told about it, say if you use a global var to hold the ftable
num.  If you use just a local i-rate variable to hold the table num,
you should be reasonably safe that it won't get used elsewhere.

Regarding tables in general, there is only one global memory space for
creating ftables.  If they're created in orch code in instr 0 space,
within an instrument, or from the score, they all get created in the
global mem space.

Hopefully that explains it better.  As for the example, I haven't
looked at the example but sounds like it is a bit confusing and could
use some improvement.

steven

On Fri, May 27, 2011 at 3:21 PM, Louis Cohen  wrote:
> Steven,
>
> Thanks for this idea. I had seen this opcode in the manual but rejected it
> because the example shows the table being created in instr 1 and then
> referenced in instr 2. This suggests that such a table is not local to a
> single instrument.
>
> Am I misunderstanding this?
>
> -Lou
>
> On May 26, 2011, at 11:25 AM, Steven Yi wrote:
>
>> If the tables are meant to exist only while an instance of an
>> instrument is around, then I'd probably use ftgentmp.
>>
>> On Tue, May 24, 2011 at 3:40 AM, kelly  hirai
>>  wrote:
>>>
>>> id look into the ftgen family of opcodes. but id be careful with event
>>> time
>>> allocation of tables if you are doing realtime stuff.
>>>
>>> kelly
>>>
>>>
>>> On Thu, 26 May 2011, Louis Cohen wrote:
>>>
>>>> After posting my last note it occurred to me that an easy way to deal
>>>> with
>>>> my problem of local tables is to write a few UDOs that access tables via
>>>> two
>>>> (or even more) indexes.
>>>>
>>>> I would still appreciate learning about other techniques to handle the
>>>> problem of tables local to a single instance of an instrument.
>>>>
>>>> thanks again!
>>>>
>>>> -Lou
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>        https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>          https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thanks, Steven,

After all of this very useful discussion, I feel most comfortable  
creating a very large table with ftgen, and dividing it into several  
smaller tables each of equal length. I'll read and write to the table  
via a simple UDO that takes a table number, a "sub-table" number and  
an index. This is no different than a 2 dimensional array, and it fits  
my needs. I can use some variation on Peiman's idea:

ir active 1
itable    ftgen    1000+ir, 0, 4096, 20, p4

...to assign "sub-tables" to instances of the instrument.

In this way I can control which instance of my instrument has access  
to which sub-table, and because I understand how ftgen allocates space  
(or at least I have a reliable model in my head) I will have control  
over exactly what's happening.

Many thanks to everyone who helped me to understand this issue better.

-Lou


On May 27, 2011, at 7:22 PM, Steven Yi wrote:

> Hi Louis,
>
> Your understanding is correct in that the table is not truly local,
> but it is somewhat "effectively" local.  With the ftgen family of
> opcodes, when 0 is used, it will look for the first available table
> number and use that when creating the table, return that as the value.
> For example, if you use ftgentmp locally with 0, it could say come
> back with an assigned ftable number of 101.  Now, another instrument
> could access that same table by using the number 101, but it'd have to
> be either lucky to know that it would get assigned 101 or would have
> to be told about it, say if you use a global var to hold the ftable
> num.  If you use just a local i-rate variable to hold the table num,
> you should be reasonably safe that it won't get used elsewhere.
>
> Regarding tables in general, there is only one global memory space for
> creating ftables.  If they're created in orch code in instr 0 space,
> within an instrument, or from the score, they all get created in the
> global mem space.
>
> Hopefully that explains it better.  As for the example, I haven't
> looked at the example but sounds like it is a bit confusing and could
> use some improvement.
>
> steven
>
> On Fri, May 27, 2011 at 3:21 PM, Louis Cohen   
> wrote:
>> Steven,
>>
>> Thanks for this idea. I had seen this opcode in the manual but  
>> rejected it
>> because the example shows the table being created in instr 1 and then
>> referenced in instr 2. This suggests that such a table is not local  
>> to a
>> single instrument.
>>
>> Am I misunderstanding this?
>>
>> -Lou
>>
>> On May 26, 2011, at 11:25 AM, Steven Yi wrote:
>>
>>> If the tables are meant to exist only while an instance of an
>>> instrument is around, then I'd probably use ftgentmp.
>>>
>>> On Tue, May 24, 2011 at 3:40 AM, kelly  hirai
>>>  wrote:
>>>>
>>>> id look into the ftgen family of opcodes. but id be careful with  
>>>> event
>>>> time
>>>> allocation of tables if you are doing realtime stuff.
>>>>
>>>> kelly
>>>>
>>>>
>>>> On Thu, 26 May 2011, Louis Cohen wrote:
>>>>
>>>>> After posting my last note it occurred to me that an easy way to  
>>>>> deal
>>>>> with
>>>>> my problem of local tables is to write a few UDOs that access  
>>>>> tables via
>>>>> two
>>>>> (or even more) indexes.
>>>>>
>>>>> I would still appreciate learning about other techniques to  
>>>>> handle the
>>>>> problem of tables local to a single instance of an instrument.
>>>>>
>>>>> thanks again!
>>>>>
>>>>> -Lou
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>        https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>>> "unsubscribe
>>>>> csound"
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>          https://sourceforge.net/tracker/? 
>>>> group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/? 
>>> group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>



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"