Hello,

I guess this is a question for Øyvind.

Is there any way to know when the last index of 'ichannelmasks' has
been read? I am trying to find a way to read through the table only
once instead of looping it. This would for instance allow the phasor
used as time-pointer to be synchronized with the reading of the
masking table (e.g. both start and end together every time).

Thanks in advance.

Peiman


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"

Ah, that is an interesting question.
And I'm actually working together with Thom Johansen on some extra
partikkel related opcodes. These will work together with partikkel in
the same manner as partikkelsync does today, reading or setting
internal parameters in partikkel (like the masking index for
instance).
Now, until those opcodes are ready, you could maybe use this workaround:

- use the same masking index for star and stop (loop points)
- write your channel mask value to the table at k-rate
e.g.
ichannelmasks	ftgentmp	0, 0, 4, -2,  0, 0,  0
kchanmod	line 0, p3, 1
	tablew	kchanmod, 2, ichannelmasks
This effectively converts the masking functions from "grain rate
update" to k-rate, and in some ways you might say that it defeats the
purpose of masking,
but sometimes you need a single k-rate value to control the parameter
(e.g. output channel), and in that case this is the way to do it.

Feel free to ask more if the above does not seem clear.
all best
Oeyind


2011/3/15 peiman khosravi :
> Hello,
>
> I guess this is a question for Øyvind.
>
> Is there any way to know when the last index of 'ichannelmasks' has
> been read? I am trying to find a way to read through the table only
> once instead of looping it. This would for instance allow the phasor
> used as time-pointer to be synchronized with the reading of the
> masking table (e.g. both start and end together every time).
>
> Thanks in advance.
>
> Peiman
>
>
> 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 very much Oeyvind. That makes sense. So I could bypass the
masking and then use phasor as a pointer into the sample and another
table that contains the masking values:

ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 0,  0
ichannelmasks       ftgentmp        0, 0, 8192, -7,  0, 8192, 5

apointer        phasor  ispeed / ifildur
kndx		downsamp	apointer

kchanmod tablei kndx, ichannelmasks, 1

		tablew  kchanmod, 2, ichannelmaskstemp

Would this be audibly different from the grain-by-grain masking that
is done internally? I guess one down side is that changes faster than
the grain-rate are ignored, which could introduce discontinuities.

I look forward to using the new opcodes they sound great. I have been
using Cmask to generate grains but now I am basically using partikkel
in the same way for a better sounding result.

Best,

Peiman


On 15 March 2011 08:43, Oeyvind Brandtsegg  wrote:
> Ah, that is an interesting question.
> And I'm actually working together with Thom Johansen on some extra
> partikkel related opcodes. These will work together with partikkel in
> the same manner as partikkelsync does today, reading or setting
> internal parameters in partikkel (like the masking index for
> instance).
> Now, until those opcodes are ready, you could maybe use this workaround:
>
> - use the same masking index for star and stop (loop points)
> - write your channel mask value to the table at k-rate
> e.g.
> ichannelmasks   ftgentmp        0, 0, 4, -2,  0, 0,  0
> kchanmod        line 0, p3, 1
>        tablew  kchanmod, 2, ichannelmasks
> This effectively converts the masking functions from "grain rate
> update" to k-rate, and in some ways you might say that it defeats the
> purpose of masking,
> but sometimes you need a single k-rate value to control the parameter
> (e.g. output channel), and in that case this is the way to do it.
>
> Feel free to ask more if the above does not seem clear.
> all best
> Oeyind
>
>
> 2011/3/15 peiman khosravi :
>> Hello,
>>
>> I guess this is a question for Øyvind.
>>
>> Is there any way to know when the last index of 'ichannelmasks' has
>> been read? I am trying to find a way to read through the table only
>> once instead of looping it. This would for instance allow the phasor
>> used as time-pointer to be synchronized with the reading of the
>> masking table (e.g. both start and end together every time).
>>
>> Thanks in advance.
>>
>> Peiman
>>
>>
>> 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"

PS I'm using max to create cool masking tables like this.

P

On 15 March 2011 09:40, peiman khosravi  wrote:
> Thanks very much Oeyvind. That makes sense. So I could bypass the
> masking and then use phasor as a pointer into the sample and another
> table that contains the masking values:
>
> ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 0,  0
> ichannelmasks       ftgentmp        0, 0, 8192, -7,  0, 8192, 5
>
> apointer        phasor  ispeed / ifildur
> kndx            downsamp        apointer
>
> kchanmod tablei kndx, ichannelmasks, 1
>
>                tablew  kchanmod, 2, ichannelmaskstemp
>
> Would this be audibly different from the grain-by-grain masking that
> is done internally? I guess one down side is that changes faster than
> the grain-rate are ignored, which could introduce discontinuities.
>
> I look forward to using the new opcodes they sound great. I have been
> using Cmask to generate grains but now I am basically using partikkel
> in the same way for a better sounding result.
>
> Best,
>
> Peiman
>
>
> On 15 March 2011 08:43, Oeyvind Brandtsegg  wrote:
>> Ah, that is an interesting question.
>> And I'm actually working together with Thom Johansen on some extra
>> partikkel related opcodes. These will work together with partikkel in
>> the same manner as partikkelsync does today, reading or setting
>> internal parameters in partikkel (like the masking index for
>> instance).
>> Now, until those opcodes are ready, you could maybe use this workaround:
>>
>> - use the same masking index for star and stop (loop points)
>> - write your channel mask value to the table at k-rate
>> e.g.
>> ichannelmasks   ftgentmp        0, 0, 4, -2,  0, 0,  0
>> kchanmod        line 0, p3, 1
>>        tablew  kchanmod, 2, ichannelmasks
>> This effectively converts the masking functions from "grain rate
>> update" to k-rate, and in some ways you might say that it defeats the
>> purpose of masking,
>> but sometimes you need a single k-rate value to control the parameter
>> (e.g. output channel), and in that case this is the way to do it.
>>
>> Feel free to ask more if the above does not seem clear.
>> all best
>> Oeyind
>>
>>
>> 2011/3/15 peiman khosravi :
>>> Hello,
>>>
>>> I guess this is a question for Øyvind.
>>>
>>> Is there any way to know when the last index of 'ichannelmasks' has
>>> been read? I am trying to find a way to read through the table only
>>> once instead of looping it. This would for instance allow the phasor
>>> used as time-pointer to be synchronized with the reading of the
>>> masking table (e.g. both start and end together every time).
>>>
>>> Thanks in advance.
>>>
>>> Peiman
>>>
>>>
>>> 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"

That is correct, you can use this method for arbitrary panning/routing
curves. And it looks interesting the way you generate the curves via
an editor in Max.
The result will not be the same, but in the use case you present here
your method will sound better and be more flexible. The channel
routing is updated internally at grain rate in any case, so the
maximum update rate is the same in both cases (internal masking or
external k-rate variable).

For a creative combination of the "k-rate table write" and the "grain
rate masking" approaches, you could also do something like this:

 ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 1,  0, 0       ;
mask length is 2 grains
 ichannelmasks1       ftgentmp        0, 0, 8192, -7,  0, 8192, 5 ;
grain trajectory 1
 ichannelmasks2       ftgentmp        0, 0, 8192, -7,  3, 8192, 1 ;
grain trajectory 2

 apointer        phasor  ispeed / ifildur
 kndx            downsamp        apointer

 kchanmod1 tablei kndx, ichannelmasks1, 1
 kchanmod2 tablei kndx, ichannelmasks2, 1

                tablew  kchanmod1, 2, ichannelmaskstemp
                tablew  kchanmod2, 3, ichannelmaskstemp

... where you will get a masking pattern of 2 grains alternating, each
following it's own trajectory.
In this specific case the first of the two will move from output 0 to
output 5, and the second of the two will move from output 3 to output
1.

You might also be glad to hear that we will implement an optional
additional parameter to partikkel that will give control over the
panning curve between each output, so one could do equal power panning
btween output 1 and 2 while still doing linear panning between output
2 and 3 for example.

best
Oeyvind

2011/3/15 peiman khosravi :
> Thanks very much Oeyvind. That makes sense. So I could bypass the
> masking and then use phasor as a pointer into the sample and another
> table that contains the masking values:
>
> ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 0,  0
> ichannelmasks       ftgentmp        0, 0, 8192, -7,  0, 8192, 5
>
> apointer        phasor  ispeed / ifildur
> kndx            downsamp        apointer
>
> kchanmod tablei kndx, ichannelmasks, 1
>
>                tablew  kchanmod, 2, ichannelmaskstemp
>
> Would this be audibly different from the grain-by-grain masking that
> is done internally? I guess one down side is that changes faster than
> the grain-rate are ignored, which could introduce discontinuities.
>
> I look forward to using the new opcodes they sound great. I have been
> using Cmask to generate grains but now I am basically using partikkel
> in the same way for a better sounding result.
>
> Best,
>
> Peiman
>
>
> On 15 March 2011 08:43, Oeyvind Brandtsegg  wrote:
>> Ah, that is an interesting question.
>> And I'm actually working together with Thom Johansen on some extra
>> partikkel related opcodes. These will work together with partikkel in
>> the same manner as partikkelsync does today, reading or setting
>> internal parameters in partikkel (like the masking index for
>> instance).
>> Now, until those opcodes are ready, you could maybe use this workaround:
>>
>> - use the same masking index for star and stop (loop points)
>> - write your channel mask value to the table at k-rate
>> e.g.
>> ichannelmasks   ftgentmp        0, 0, 4, -2,  0, 0,  0
>> kchanmod        line 0, p3, 1
>>        tablew  kchanmod, 2, ichannelmasks
>> This effectively converts the masking functions from "grain rate
>> update" to k-rate, and in some ways you might say that it defeats the
>> purpose of masking,
>> but sometimes you need a single k-rate value to control the parameter
>> (e.g. output channel), and in that case this is the way to do it.
>>
>> Feel free to ask more if the above does not seem clear.
>> all best
>> Oeyind
>>
>>
>> 2011/3/15 peiman khosravi :
>>> Hello,
>>>
>>> I guess this is a question for Øyvind.
>>>
>>> Is there any way to know when the last index of 'ichannelmasks' has
>>> been read? I am trying to find a way to read through the table only
>>> once instead of looping it. This would for instance allow the phasor
>>> used as time-pointer to be synchronized with the reading of the
>>> masking table (e.g. both start and end together every time).
>>>
>>> Thanks in advance.
>>>
>>> Peiman
>>>
>>>
>>> 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"

That looks lovely. Thanks a lot.

And I was just about to mention that it would be nice to have equal
power panning!

Is there a reason why one would want to have equal power panning only
between outputs 1 and 2?

Thanks

Peiman

On 15 March 2011 12:11, Oeyvind Brandtsegg  wrote:
> That is correct, you can use this method for arbitrary panning/routing
> curves. And it looks interesting the way you generate the curves via
> an editor in Max.
> The result will not be the same, but in the use case you present here
> your method will sound better and be more flexible. The channel
> routing is updated internally at grain rate in any case, so the
> maximum update rate is the same in both cases (internal masking or
> external k-rate variable).
>
> For a creative combination of the "k-rate table write" and the "grain
> rate masking" approaches, you could also do something like this:
>
>  ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 1,  0, 0       ;
> mask length is 2 grains
>  ichannelmasks1       ftgentmp        0, 0, 8192, -7,  0, 8192, 5 ;
> grain trajectory 1
>  ichannelmasks2       ftgentmp        0, 0, 8192, -7,  3, 8192, 1 ;
> grain trajectory 2
>
>  apointer        phasor  ispeed / ifildur
>  kndx            downsamp        apointer
>
>  kchanmod1 tablei kndx, ichannelmasks1, 1
>  kchanmod2 tablei kndx, ichannelmasks2, 1
>
>                tablew  kchanmod1, 2, ichannelmaskstemp
>                tablew  kchanmod2, 3, ichannelmaskstemp
>
> ... where you will get a masking pattern of 2 grains alternating, each
> following it's own trajectory.
> In this specific case the first of the two will move from output 0 to
> output 5, and the second of the two will move from output 3 to output
> 1.
>
> You might also be glad to hear that we will implement an optional
> additional parameter to partikkel that will give control over the
> panning curve between each output, so one could do equal power panning
> btween output 1 and 2 while still doing linear panning between output
> 2 and 3 for example.
>
> best
> Oeyvind
>
> 2011/3/15 peiman khosravi :
>> Thanks very much Oeyvind. That makes sense. So I could bypass the
>> masking and then use phasor as a pointer into the sample and another
>> table that contains the masking values:
>>
>> ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 0,  0
>> ichannelmasks       ftgentmp        0, 0, 8192, -7,  0, 8192, 5
>>
>> apointer        phasor  ispeed / ifildur
>> kndx            downsamp        apointer
>>
>> kchanmod tablei kndx, ichannelmasks, 1
>>
>>                tablew  kchanmod, 2, ichannelmaskstemp
>>
>> Would this be audibly different from the grain-by-grain masking that
>> is done internally? I guess one down side is that changes faster than
>> the grain-rate are ignored, which could introduce discontinuities.
>>
>> I look forward to using the new opcodes they sound great. I have been
>> using Cmask to generate grains but now I am basically using partikkel
>> in the same way for a better sounding result.
>>
>> Best,
>>
>> Peiman
>>
>>
>> On 15 March 2011 08:43, Oeyvind Brandtsegg  wrote:
>>> Ah, that is an interesting question.
>>> And I'm actually working together with Thom Johansen on some extra
>>> partikkel related opcodes. These will work together with partikkel in
>>> the same manner as partikkelsync does today, reading or setting
>>> internal parameters in partikkel (like the masking index for
>>> instance).
>>> Now, until those opcodes are ready, you could maybe use this workaround:
>>>
>>> - use the same masking index for star and stop (loop points)
>>> - write your channel mask value to the table at k-rate
>>> e.g.
>>> ichannelmasks   ftgentmp        0, 0, 4, -2,  0, 0,  0
>>> kchanmod        line 0, p3, 1
>>>        tablew  kchanmod, 2, ichannelmasks
>>> This effectively converts the masking functions from "grain rate
>>> update" to k-rate, and in some ways you might say that it defeats the
>>> purpose of masking,
>>> but sometimes you need a single k-rate value to control the parameter
>>> (e.g. output channel), and in that case this is the way to do it.
>>>
>>> Feel free to ask more if the above does not seem clear.
>>> all best
>>> Oeyind
>>>
>>>
>>> 2011/3/15 peiman khosravi :
>>>> Hello,
>>>>
>>>> I guess this is a question for Øyvind.
>>>>
>>>> Is there any way to know when the last index of 'ichannelmasks' has
>>>> been read? I am trying to find a way to read through the table only
>>>> once instead of looping it. This would for instance allow the phasor
>>>> used as time-pointer to be synchronized with the reading of the
>>>> masking table (e.g. both start and end together every time).
>>>>
>>>> Thanks in advance.
>>>>
>>>> Peiman
>>>>
>>>>
>>>> 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"

hehe, well, mainly it's done this way for full flexibility (you define
a separate panning curve for each channel transition),
one configuration that I commonly use is to route output 1 and 2 to
dry left and right, then use the other outputs for effects (that end
up panned somewhere in the stereo field as well), in this case equal
power routing between the different effect sends may not be desirable.
best
Oeyvind

2011/3/15 peiman khosravi :
> That looks lovely. Thanks a lot.
>
> And I was just about to mention that it would be nice to have equal
> power panning!
>
> Is there a reason why one would want to have equal power panning only
> between outputs 1 and 2?
>
> Thanks
>
> Peiman
>
> On 15 March 2011 12:11, Oeyvind Brandtsegg  wrote:
>> That is correct, you can use this method for arbitrary panning/routing
>> curves. And it looks interesting the way you generate the curves via
>> an editor in Max.
>> The result will not be the same, but in the use case you present here
>> your method will sound better and be more flexible. The channel
>> routing is updated internally at grain rate in any case, so the
>> maximum update rate is the same in both cases (internal masking or
>> external k-rate variable).
>>
>> For a creative combination of the "k-rate table write" and the "grain
>> rate masking" approaches, you could also do something like this:
>>
>>  ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 1,  0, 0       ;
>> mask length is 2 grains
>>  ichannelmasks1       ftgentmp        0, 0, 8192, -7,  0, 8192, 5 ;
>> grain trajectory 1
>>  ichannelmasks2       ftgentmp        0, 0, 8192, -7,  3, 8192, 1 ;
>> grain trajectory 2
>>
>>  apointer        phasor  ispeed / ifildur
>>  kndx            downsamp        apointer
>>
>>  kchanmod1 tablei kndx, ichannelmasks1, 1
>>  kchanmod2 tablei kndx, ichannelmasks2, 1
>>
>>                tablew  kchanmod1, 2, ichannelmaskstemp
>>                tablew  kchanmod2, 3, ichannelmaskstemp
>>
>> ... where you will get a masking pattern of 2 grains alternating, each
>> following it's own trajectory.
>> In this specific case the first of the two will move from output 0 to
>> output 5, and the second of the two will move from output 3 to output
>> 1.
>>
>> You might also be glad to hear that we will implement an optional
>> additional parameter to partikkel that will give control over the
>> panning curve between each output, so one could do equal power panning
>> btween output 1 and 2 while still doing linear panning between output
>> 2 and 3 for example.
>>
>> best
>> Oeyvind
>>
>> 2011/3/15 peiman khosravi :
>>> Thanks very much Oeyvind. That makes sense. So I could bypass the
>>> masking and then use phasor as a pointer into the sample and another
>>> table that contains the masking values:
>>>
>>> ichannelmaskstemp   ftgentmp        0, 0, 4, -2,  0, 0,  0
>>> ichannelmasks       ftgentmp        0, 0, 8192, -7,  0, 8192, 5
>>>
>>> apointer        phasor  ispeed / ifildur
>>> kndx            downsamp        apointer
>>>
>>> kchanmod tablei kndx, ichannelmasks, 1
>>>
>>>                tablew  kchanmod, 2, ichannelmaskstemp
>>>
>>> Would this be audibly different from the grain-by-grain masking that
>>> is done internally? I guess one down side is that changes faster than
>>> the grain-rate are ignored, which could introduce discontinuities.
>>>
>>> I look forward to using the new opcodes they sound great. I have been
>>> using Cmask to generate grains but now I am basically using partikkel
>>> in the same way for a better sounding result.
>>>
>>> Best,
>>>
>>> Peiman
>>>
>>>
>>> On 15 March 2011 08:43, Oeyvind Brandtsegg  wrote:
>>>> Ah, that is an interesting question.
>>>> And I'm actually working together with Thom Johansen on some extra
>>>> partikkel related opcodes. These will work together with partikkel in
>>>> the same manner as partikkelsync does today, reading or setting
>>>> internal parameters in partikkel (like the masking index for
>>>> instance).
>>>> Now, until those opcodes are ready, you could maybe use this workaround:
>>>>
>>>> - use the same masking index for star and stop (loop points)
>>>> - write your channel mask value to the table at k-rate
>>>> e.g.
>>>> ichannelmasks   ftgentmp        0, 0, 4, -2,  0, 0,  0
>>>> kchanmod        line 0, p3, 1
>>>>        tablew  kchanmod, 2, ichannelmasks
>>>> This effectively converts the masking functions from "grain rate
>>>> update" to k-rate, and in some ways you might say that it defeats the
>>>> purpose of masking,
>>>> but sometimes you need a single k-rate value to control the parameter
>>>> (e.g. output channel), and in that case this is the way to do it.
>>>>
>>>> Feel free to ask more if the above does not seem clear.
>>>> all best
>>>> Oeyind
>>>>
>>>>
>>>> 2011/3/15 peiman khosravi :
>>>>> Hello,
>>>>>
>>>>> I guess this is a question for Øyvind.
>>>>>
>>>>> Is there any way to know when the last index of 'ichannelmasks' has
>>>>> been read? I am trying to find a way to read through the table only
>>>>> once instead of looping it. This would for instance allow the phasor
>>>>> used as time-pointer to be synchronized with the reading of the
>>>>> masking table (e.g. both start and end together every time).
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Peiman
>>>>>
>>>>>
>>>>> 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"