Hello

I've updated partikkel in CVS with some bug fixes and optimizations.
I'd like to update the manual accordingly, but it's been som long
since I edited the manual that I've forgotten how to do it. Very
sorry, but could someone please remind me.

Also, I've made a new opcode together with Thom Johansen, and I wonder
if it could be included in the official version.
It is called modmatrix, and it is a matrix mixer for modulation
signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
etc) and M parameters (amp, frequency, ... other synthesis parameters
etc.), we can route each modulator with a dynamic scaling coefficient
to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
full scale and parameter 2 with half that range, and so on. I started
doing this with vmultv and tabsum opcodes but it became quite slow
when the matrix became large.
How would I proceed to check in a new opcode (forgot that too, only
did it once before...)

best
Oeyvind

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

On 11/17/09, Oeyvind Brandtsegg  wrote:
> Hello
>
> I've updated partikkel in CVS with some bug fixes and optimizations.
> I'd like to update the manual accordingly, but it's been som long
> since I edited the manual that I've forgotten how to do it. Very
> sorry, but could someone please remind me.
>

You need to find the xml entry for the opcode, in this case it should
be in opcodes/partikkel.xml.

Just edit the test there, but remember you are editing xml, so many
characters like "<" need to be given codes like "<". What you can
do, is just modify the file and send it to me, I'll check it and
commit it to cvs. Or just commit and let me know so I can check it.

If you need a reminder on cvs, google will provide countless answers.

Cheers,
Andrés

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Oeyvind Brandtsegg wrote:
...
> Also, I've made a new opcode together with Thom Johansen, and I wonder
> if it could be included in the official version.
> It is called modmatrix, and it is a matrix mixer for modulation
> signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
> etc) and M parameters (amp, frequency, ... other synthesis parameters
> etc.), we can route each modulator with a dynamic scaling coefficient
> to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
> full scale and parameter 2 with half that range, and so on. I started
> doing this with vmultv and tabsum opcodes but it became quite slow
> when the matrix became large.

Couldn't you use the zak patch system instead? 
http://www.csounds.com/manual/html/ZakTop.html

/Jonatan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It would be possible, but very slow when you have a large number of
modulators and parameters, and the routing should be flexible (all to
all). With modmatrix you will only spend CPU cycles multiplying and
adding modulators that are actually in use (can be few). For my
current use I have 32 modulators affecting 103 parameters, giving a
matrix size of 32x128. This used about 4-5%CPU when implemented in
csound code, regardless of how many modulators were actually used. If
all modulators are active, the CPU usage is more or less cut in half,
if only a few modulators are active CPU usage is close to nothing with
modmatrix.
best
Oeyvind

2009/11/17 Jonatan Liljedahl :
> Oeyvind Brandtsegg wrote:
> ...
>> Also, I've made a new opcode together with Thom Johansen, and I wonder
>> if it could be included in the official version.
>> It is called modmatrix, and it is a matrix mixer for modulation
>> signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
>> etc) and M parameters (amp, frequency, ... other synthesis parameters
>> etc.), we can route each modulator with a dynamic scaling coefficient
>> to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
>> full scale and parameter 2 with half that range, and so on. I started
>> doing this with vmultv and tabsum opcodes but it became quite slow
>> when the matrix became large.
>
> Couldn't you use the zak patch system instead?
> http://www.csounds.com/manual/html/ZakTop.html
>
> /Jonatan
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think the existing linear algebra opcodes could do this efficiently.

Mkg

On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg" <obrandts@gmail.com> wrote:

It would be possible, but very slow when you have a large number of
modulators and parameters, and the routing should be flexible (all to
all). With modmatrix you will only spend CPU cycles multiplying and
adding modulators that are actually in use (can be few). For my
current use I have 32 modulators affecting 103 parameters, giving a
matrix size of 32x128. This used about 4-5%CPU when implemented in
csound code, regardless of how many modulators were actually used. If
all modulators are active, the CPU usage is more or less cut in half,
if only a few modulators are active CPU usage is close to nothing with
modmatrix.
best
Oeyvind

2009/11/17 Jonatan Liljedahl <lijon@kymatica.com>:

> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together with Thom Johansen, and I...

Yes, they probably could. But it still seems even more effective to do
it in modmatrix, as multiplying and adding is done in one operation
instead of two (unless there is something I don't understand about the
linear algebra opcodes, ...this is likely), and I forgot to add that
there is a "kupdate" flag to modmatrix that can optimize the matrix
calculations if the scaling coefficients does not change too often.
Moreover, the parameter values reside in normal Csound ftables all the
time, so saving and recalling "presets" is as easy as ftload/ftsave.

best
Oeyvind

2009/11/17 Michael Gogins :
> I think the existing linear algebra opcodes could do this efficiently.
>
> Mkg
>
> On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg"  wrote:
>
> It would be possible, but very slow when you have a large number of
> modulators and parameters, and the routing should be flexible (all to
> all). With modmatrix you will only spend CPU cycles multiplying and
> adding modulators that are actually in use (can be few). For my
> current use I have 32 modulators affecting 103 parameters, giving a
> matrix size of 32x128. This used about 4-5%CPU when implemented in
> csound code, regardless of how many modulators were actually used. If
> all modulators are active, the CPU usage is more or less cut in half,
> if only a few modulators are active CPU usage is close to nothing with
> modmatrix.
> best
> Oeyvind
>
> 2009/11/17 Jonatan Liljedahl :
>
>> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together
>> with Thom Johansen, and I...
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

is it not the case that the linear algebra opcodes only work in doubles?



> I think the existing linear algebra opcodes could do this efficiently.
>
> Mkg
>
> On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg"  wrote:
>
> It would be possible, but very slow when you have a large number of
> modulators and parameters, and the routing should be flexible (all to
> all). With modmatrix you will only spend CPU cycles multiplying and
> adding modulators that are actually in use (can be few). For my
> current use I have 32 modulators affecting 103 parameters, giving a
> matrix size of 32x128. This used about 4-5%CPU when implemented in
> csound code, regardless of how many modulators were actually used. If
> all modulators are active, the CPU usage is more or less cut in half,
> if only a few modulators are active CPU usage is close to nothing with
> modmatrix.
> best
> Oeyvind
>
> 2009/11/17 Jonatan Liljedahl :
>
>> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together
> with Thom Johansen, and I...
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.
> http://p.sf.net/sfu/bobj-july_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The linear algebra opcodes can do the adding and multiplying in one
operation, of course, and in several different ways. But they do not
use sparse matrices, so the operations are applied to each element of
the matrix, even if the operation should produce zero. So, if your
opcodes also do not use spare matrices, the linear algebra opcodes
should be at least as efficient. If your opcodes do use spare
matrices, then it would depend on the details. If you use a map or
hashtable for the matrices, then I would expect the linear algebra
operations to be more efficient for matrices that are only moderately
sparse. Large, quite sparse matrices would favor your opcodes in that
case.

If your opcodes use some sort of iteration over linked lists or ragged
arrays, then your opcodes should be more efficient for just about any
sparse matrix.

Regards,
Mike

On Tue, Nov 17, 2009 at 9:06 AM,   wrote:
> is it not the case that the linear algebra opcodes only work in doubles?
>
>
>
>> I think the existing linear algebra opcodes could do this efficiently.
>>
>> Mkg
>>
>> On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg"  wrote:
>>
>> It would be possible, but very slow when you have a large number of
>> modulators and parameters, and the routing should be flexible (all to
>> all). With modmatrix you will only spend CPU cycles multiplying and
>> adding modulators that are actually in use (can be few). For my
>> current use I have 32 modulators affecting 103 parameters, giving a
>> matrix size of 32x128. This used about 4-5%CPU when implemented in
>> csound code, regardless of how many modulators were actually used. If
>> all modulators are active, the CPU usage is more or less cut in half,
>> if only a few modulators are active CPU usage is close to nothing with
>> modmatrix.
>> best
>> Oeyvind
>>
>> 2009/11/17 Jonatan Liljedahl :
>>
>>> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together
>> with Thom Johansen, and I...
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.
>> http://p.sf.net/sfu/bobj-july_______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We use sparse matrixes and they can be quite large and quite sparse so
I guess it will be most efficient with the modmatrix opcode.
best Oeyvind

2009/11/17 Michael Gogins :
> The linear algebra opcodes can do the adding and multiplying in one
> operation, of course, and in several different ways. But they do not
> use sparse matrices, so the operations are applied to each element of
> the matrix, even if the operation should produce zero. So, if your
> opcodes also do not use spare matrices, the linear algebra opcodes
> should be at least as efficient. If your opcodes do use spare
> matrices, then it would depend on the details. If you use a map or
> hashtable for the matrices, then I would expect the linear algebra
> operations to be more efficient for matrices that are only moderately
> sparse. Large, quite sparse matrices would favor your opcodes in that
> case.
>
> If your opcodes use some sort of iteration over linked lists or ragged
> arrays, then your opcodes should be more efficient for just about any
> sparse matrix.
>
> Regards,
> Mike
>
> On Tue, Nov 17, 2009 at 9:06 AM,   wrote:
>> is it not the case that the linear algebra opcodes only work in doubles?
>>
>>
>>
>>> I think the existing linear algebra opcodes could do this efficiently.
>>>
>>> Mkg
>>>
>>> On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg"  wrote:
>>>
>>> It would be possible, but very slow when you have a large number of
>>> modulators and parameters, and the routing should be flexible (all to
>>> all). With modmatrix you will only spend CPU cycles multiplying and
>>> adding modulators that are actually in use (can be few). For my
>>> current use I have 32 modulators affecting 103 parameters, giving a
>>> matrix size of 32x128. This used about 4-5%CPU when implemented in
>>> csound code, regardless of how many modulators were actually used. If
>>> all modulators are active, the CPU usage is more or less cut in half,
>>> if only a few modulators are active CPU usage is close to nothing with
>>> modmatrix.
>>> best
>>> Oeyvind
>>>
>>> 2009/11/17 Jonatan Liljedahl :
>>>
>>>> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together
>>> with Thom Johansen, and I...
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus
>>> on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.
>>> http://p.sf.net/sfu/bobj-july_______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That sounds correct...

Mike

On Tue, Nov 17, 2009 at 10:33 AM, Oeyvind Brandtsegg  wrote:
> We use sparse matrixes and they can be quite large and quite sparse so
> I guess it will be most efficient with the modmatrix opcode.
> best Oeyvind
>
> 2009/11/17 Michael Gogins :
>> The linear algebra opcodes can do the adding and multiplying in one
>> operation, of course, and in several different ways. But they do not
>> use sparse matrices, so the operations are applied to each element of
>> the matrix, even if the operation should produce zero. So, if your
>> opcodes also do not use spare matrices, the linear algebra opcodes
>> should be at least as efficient. If your opcodes do use spare
>> matrices, then it would depend on the details. If you use a map or
>> hashtable for the matrices, then I would expect the linear algebra
>> operations to be more efficient for matrices that are only moderately
>> sparse. Large, quite sparse matrices would favor your opcodes in that
>> case.
>>
>> If your opcodes use some sort of iteration over linked lists or ragged
>> arrays, then your opcodes should be more efficient for just about any
>> sparse matrix.
>>
>> Regards,
>> Mike
>>
>> On Tue, Nov 17, 2009 at 9:06 AM,   wrote:
>>> is it not the case that the linear algebra opcodes only work in doubles?
>>>
>>>
>>>
>>>> I think the existing linear algebra opcodes could do this efficiently.
>>>>
>>>> Mkg
>>>>
>>>> On Nov 17, 2009 8:24 AM, "Oeyvind Brandtsegg"  wrote:
>>>>
>>>> It would be possible, but very slow when you have a large number of
>>>> modulators and parameters, and the routing should be flexible (all to
>>>> all). With modmatrix you will only spend CPU cycles multiplying and
>>>> adding modulators that are actually in use (can be few). For my
>>>> current use I have 32 modulators affecting 103 parameters, giving a
>>>> matrix size of 32x128. This used about 4-5%CPU when implemented in
>>>> csound code, regardless of how many modulators were actually used. If
>>>> all modulators are active, the CPU usage is more or less cut in half,
>>>> if only a few modulators are active CPU usage is close to nothing with
>>>> modmatrix.
>>>> best
>>>> Oeyvind
>>>>
>>>> 2009/11/17 Jonatan Liljedahl :
>>>>
>>>>> Oeyvind Brandtsegg wrote: > ... >> Also, I've made a new opcode together
>>>> with Thom Johansen, and I...
>>>> ------------------------------------------------------------------------------
>>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>>> 30-Day
>>>> trial. Simplify your report design, integration and deployment - and focus
>>>> on
>>>> what you do best, core application coding. Discover what's new with
>>>> Crystal Reports now.
>>>> http://p.sf.net/sfu/bobj-july_______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I see, sounds interesting. Would be nice to see some example code of 
modmatrix usage. BTW, why not add audio signals too?

Oeyvind Brandtsegg wrote:
> It would be possible, but very slow when you have a large number of
> modulators and parameters, and the routing should be flexible (all to
> all). With modmatrix you will only spend CPU cycles multiplying and
> adding modulators that are actually in use (can be few). For my
> current use I have 32 modulators affecting 103 parameters, giving a
> matrix size of 32x128. This used about 4-5%CPU when implemented in
> csound code, regardless of how many modulators were actually used. If
> all modulators are active, the CPU usage is more or less cut in half,
> if only a few modulators are active CPU usage is close to nothing with
> modmatrix.
> best
> Oeyvind
> 
> 2009/11/17 Jonatan Liljedahl :
>> Oeyvind Brandtsegg wrote:
>> ...
>>> Also, I've made a new opcode together with Thom Johansen, and I wonder
>>> if it could be included in the official version.
>>> It is called modmatrix, and it is a matrix mixer for modulation
>>> signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
>>> etc) and M parameters (amp, frequency, ... other synthesis parameters
>>> etc.), we can route each modulator with a dynamic scaling coefficient
>>> to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
>>> full scale and parameter 2 with half that range, and so on. I started
>>> doing this with vmultv and tabsum opcodes but it became quite slow
>>> when the matrix became large.
>> Couldn't you use the zak patch system instead?
>> http://www.csounds.com/manual/html/ZakTop.html
>>
>> /Jonatan
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Tue, 2009-11-17 at 14:23 +0100, Oeyvind Brandtsegg wrote:
> It would be possible, but very slow when you have a large number of
> modulators and parameters, and the routing should be flexible (all to
> all). With modmatrix you will only spend CPU cycles multiplying and
> adding modulators that are actually in use (can be few). For my
> current use I have 32 modulators affecting 103 parameters, giving a
> matrix size of 32x128. This used about 4-5%CPU when implemented in
> csound code, regardless of how many modulators were actually used. If
> all modulators are active, the CPU usage is more or less cut in half,
> if only a few modulators are active CPU usage is close to nothing with
> modmatrix.

Nice! That sounds great. Having done the same type of thing all in
csound myself, using an opcode and doing it in C would be much better
for some use cases.

Iain

> best
> Oeyvind
> 
> 2009/11/17 Jonatan Liljedahl :
> > Oeyvind Brandtsegg wrote:
> > ...
> >> Also, I've made a new opcode together with Thom Johansen, and I wonder
> >> if it could be included in the official version.
> >> It is called modmatrix, and it is a matrix mixer for modulation
> >> signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
> >> etc) and M parameters (amp, frequency, ... other synthesis parameters
> >> etc.), we can route each modulator with a dynamic scaling coefficient
> >> to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
> >> full scale and parameter 2 with half that range, and so on. I started
> >> doing this with vmultv and tabsum opcodes but it became quite slow
> >> when the matrix became large.
> >
> > Couldn't you use the zak patch system instead?
> > http://www.csounds.com/manual/html/ZakTop.html
> >
> > /Jonatan
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> > trial. Simplify your report design, integration and deployment - and focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I will release a (quite large) instrument using this soon (hopefully
before end of this year), and of course provide a simple example for
the manual.
best
Oeyvind

2009/11/17 Jonatan Liljedahl :
> I see, sounds interesting. Would be nice to see some example code of
> modmatrix usage. BTW, why not add audio signals too?
>
> Oeyvind Brandtsegg wrote:
>> It would be possible, but very slow when you have a large number of
>> modulators and parameters, and the routing should be flexible (all to
>> all). With modmatrix you will only spend CPU cycles multiplying and
>> adding modulators that are actually in use (can be few). For my
>> current use I have 32 modulators affecting 103 parameters, giving a
>> matrix size of 32x128. This used about 4-5%CPU when implemented in
>> csound code, regardless of how many modulators were actually used. If
>> all modulators are active, the CPU usage is more or less cut in half,
>> if only a few modulators are active CPU usage is close to nothing with
>> modmatrix.
>> best
>> Oeyvind
>>
>> 2009/11/17 Jonatan Liljedahl :
>>> Oeyvind Brandtsegg wrote:
>>> ...
>>>> Also, I've made a new opcode together with Thom Johansen, and I wonder
>>>> if it could be included in the official version.
>>>> It is called modmatrix, and it is a matrix mixer for modulation
>>>> signals. Say we have N modulators (LFOs, Envelopes, Analysis signals
>>>> etc) and M parameters (amp, frequency, ... other synthesis parameters
>>>> etc.), we can route each modulator with a dynamic scaling coefficient
>>>> to each parameter separately. E.g. so LFO1 can affect parameter 1 on a
>>>> full scale and parameter 2 with half that range, and so on. I started
>>>> doing this with vmultv and tabsum opcodes but it became quite slow
>>>> when the matrix became large.
>>> Couldn't you use the zak patch system instead?
>>> http://www.csounds.com/manual/html/ZakTop.html
>>>
>>> /Jonatan
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net