Hello,

Currently partikkel loops through a function table to read read the per grain parameters (e.g. channel number). I find this very useful for distributing a sound among several loudspeakers with user-defined bias. And although I've not tried it, tabmorph can be used to gradually change from one pattern of 'distribution' to another.  

What I'm missing is a mechanism of reading the table values not only sequentially but also using different patterns. For example, back&forth, random distributions (uniform, Gaussian, exponential, serial...), stutter mode (iterating random values based on a user define probability). And if one could change between these different patterns at k-rate then suddenly the possibilities are enormous.

I'm not sure what is the best way to go about this but just thinking aloud.

Thanks
Peiman      

Hi Peiman,

I thought about this scenario, well perhaps I did not envision
hundreds of channels, but at least providing support for more than 8.
If you run several instances of partikkel, you can link them by using
the "async" parameter of the second (third, fourth ...) so that the
grain clock of those generators would be linked to first one (master).

Now, for the arbitrary masking sequences, I might have a solution to
that too. Not terribly elegant, but it might just work.
Some time ago I got Thom help me write two new support opvodes for
partikkel: partikkelget and partikkelset. These can read the "mask
index" of a running partikkel instance (of course this may be
different for the different mask parameters), and also similarly set
the index.

These are not heavily tested yet, so still not released. But it seems
it is time to give it a go.
Syntax for partikkelset/get is

partikkelset kparameterindex kvalue iopcodeid
kvalue partikkelget kparameterindex iopcodeid

mask parameter indices:
0: gain mask
1: sweep start
2: sweet end
3: fm amplitude
4: channel mask
5: waveform gain

Using this, you might provide your own masking index generator and
create any sequence or distribution you need.
A potential problem may occur if you need exact masking index control
with precise timing at very high grain rates,
as the index control is at k-rate, so if you're running a grain rate
of more than kr/2 you might miss some values (in which case
partikkel's internal index increment would be active until a new index
is set at the next k-pass).

Now, I haven't finished any examples to show this, but did try to
prepare the opcodes for this kind of flexibility. I'm glad you push
the limits and will also be happy to try to help you make it do what
you need.

best
Oeyvind

Btw. For John (or other repo admin): do I have git write access?
Haven't tried writing to repo since the conversion to git.


2012/7/21 peiman khosravi <peimankhosravi@gmail.com>:

> Another request: is it possible to make partikkel's channel output channels
> arbitrarily large? I'm considering an installation in the near future that
> will include many tweeters (think in the region of hundreds). Haven't worked
> out how I'll deal with outputting all those channels but I guess I'll have
> to go for really cheap speakers and converters (I only intend to use the
> tweerters as impulse generators) but I think in the software domain
> partikkel would be really handy.
>
> Thanks
> P
>
> On 21 July 2012 13:04, peiman khosravi <peimankhosravi@gmail.com> wrote:
>>
>> Hello,
>>
>> Currently partikkel loops through a function table to read read the per
>> grain parameters (e.g. channel number). I find this very useful for
>> distributing a sound among several loudspeakers with user-defined bias. And
>> although I've not tried it, tabmorph can be used to gradually change from
>> one pattern of 'distribution' to another.
>>
>> What I'm missing is a mechanism of reading the table values not only
>> sequentially but also using different patterns. For example, back&forth,
>> random distributions (uniform, Gaussian, exponential, serial...), stutter
>> mode (iterating random values based on a user define probability). And if
>> one could change between these different patterns at k-rate then suddenly
>> the possibilities are enormous.
>>
>> I'm not sure what is the best way to go about this but just thinking
>> aloud.
>>
>> Thanks
>> Peiman
>
>

--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


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 Peiman,

In some cases it makes perfect sense to disable the masking patterns,
by setting the loop start and end points to the same, and rewriting
the table data at that index by using external (to partikkel) signal
generators.
(or was that perhaps not what you asked?, sorry if I misunderstood).
The grain masking feature is both for convenience, optimization, and
synchronization. At very high grain rates one might need to rewrite
the mask value at audio rate to ensure it is updated between each new
grain, but it seemed like a waste to do this as most of the
"bandwidth" of that signal would not be used, and it would also create
the need for a trigger mechnaism (like you suggest in using
partikkelsync output to generate new values). Considering that event
generation and/or conditionals is not normally available at higher
than k rate and that the audio signal is a vector of ksmps length, the
triggering mechanism would most probably create the need for a local
ksmps=1 (or some low value). There could be some way of doing this
that I have overlooked (?).

The partikkelget/set opcodes were originally intended to be used for
re-synchronization of grain masking sequences (either using a single
instance, syncing mask patterns for different parameters; or syncing
different partikkel instances). For your use, as I said, not terribly
elegant, but might solve some special cases.

...but, to simplify the problem, if your grain rate is always below kr
and you want the "mask" to be a signal rather than a pattern, then it
is most probably better to use table rewriting of a single mask
(disabling the partikkel masking patterns). Sorry about the kr/2
limitation I mentioned in the previous email, it was incorrect: grain
rate <= kr should be fine for the table rewriting of single masks.

With respect to handling channel masks for more than 8 channels, I
think I might implement a mapping layer allowing me to specify the
channel masks directly.
For example, a specificed channel mask of 15 (zero indexed) would be written as:
- channel mask 7 for partikkel instance 2
- gain mask multiplied by zero for all partikkel instances except instance 2

best
Oeyvind


2012/7/21 peiman khosravi <peimankhosravi@gmail.com>:

> Hi Oeyvind,
>
> Thanks for the super detailed reply. Some thoughts/questions below.
>
> On 21 July 2012 22:23, Oeyvind Brandtsegg <oyvind.brandtsegg@ntnu.no> wrote:
>>
>> Hi Peiman,
>>
>> I thought about this scenario, well perhaps I did not envision
>> hundreds of channels, but at least providing support for more than 8.
>> If you run several instances of partikkel, you can link them by using
>> the "async" parameter of the second (third, fourth ...) so that the
>> grain clock of those generators would be linked to first one (master).
>
>
> This would work but I would need to deal with the masking in a far more
> complicated manner (if you want grain-by-grain panning for all those
> channels). I guess it could be done using a combination amplitude and
> channel masking but then I couldn't use the channel masking table. Which
> brings us to your suggestion below.
>
>>
>> Now, for the arbitrary masking sequences, I might have a solution to
>> that too. Not terribly elegant, but it might just work.
>> Some time ago I got Thom help me write two new support opvodes for
>> partikkel: partikkelget and partikkelset. These can read the "mask
>> index" of a running partikkel instance (of course this may be
>> different for the different mask parameters), and also similarly set
>> the index.
>
>
> This is really useful, other than being more convenient how is it different
> from writing to the masking tables manually at k-rate?
> couldn't this be changed to work at  signal rate? Then one could use the
> output of partikkelsync to generate a new value in sync with the grain
> clock. Does that make sense or am I missing something? Of course then the
> values would need to be generated by a pattern generator, then we need a
> pattern library!!!
>
> Thanks
>
> Peiman
>
>>
>> These are not heavily tested yet, so still not released. But it seems
>> it is time to give it a go.
>> Syntax for partikkelset/get is
>>
>> partikkelset kparameterindex kvalue iopcodeid
>> kvalue partikkelget kparameterindex iopcodeid
>>
>> mask parameter indices:
>> 0: gain mask
>> 1: sweep start
>> 2: sweet end
>> 3: fm amplitude
>> 4: channel mask
>> 5: waveform gain
>>
>> Using this, you might provide your own masking index generator and
>> create any sequence or distribution you need.
>> A potential problem may occur if you need exact masking index control
>> with precise timing at very high grain rates,
>> as the index control is at k-rate, so if you're running a grain rate
>> of more than kr/2 you might miss some values (in which case
>> partikkel's internal index increment would be active until a new index
>> is set at the next k-pass).
>>
>> Now, I haven't finished any examples to show this, but did try to
>> prepare the opcodes for this kind of flexibility. I'm glad you push
>> the limits and will also be happy to try to help you make it do what
>> you need.
>>
>> best
>> Oeyvind
>>
>> Btw. For John (or other repo admin): do I have git write access?
>> Haven't tried writing to repo since the conversion to git.
>>
>>
>> 2012/7/21 peiman khosravi <peimankhosravi@gmail.com>:
>> > Another request: is it possible to make partikkel's channel output
>> > channels
>> > arbitrarily large? I'm considering an installation in the near future
>> > that
>> > will include many tweeters (think in the region of hundreds). Haven't
>> > worked
>> > out how I'll deal with outputting all those channels but I guess I'll
>> > have
>> > to go for really cheap speakers and converters (I only intend to use the
>> > tweerters as impulse generators) but I think in the software domain
>> > partikkel would be really handy.
>> >
>> > Thanks
>> > P
>> >
>> > On 21 July 2012 13:04, peiman khosravi <peimankhosravi@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Currently partikkel loops through a function table to read read the per
>> >> grain parameters (e.g. channel number). I find this very useful for
>> >> distributing a sound among several loudspeakers with user-defined bias.
>> >> And
>> >> although I've not tried it, tabmorph can be used to gradually change
>> >> from
>> >> one pattern of 'distribution' to another.
>> >>
>> >> What I'm missing is a mechanism of reading the table values not only
>> >> sequentially but also using different patterns. For example,
>> >> back&forth,
>> >> random distributions (uniform, Gaussian, exponential, serial...),
>> >> stutter
>> >> mode (iterating random values based on a user define probability). And
>> >> if
>> >> one could change between these different patterns at k-rate then
>> >> suddenly
>> >> the possibilities are enormous.
>> >>
>> >> I'm not sure what is the best way to go about this but just thinking
>> >> aloud.
>> >>
>> >> Thanks
>> >> Peiman
>> >
>> >
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
>>
>>
>> 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"
>>
>



--

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp


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"