Hi,

I was just thinking that having the ability to create a bank of opcodes using one line would be very handy now that there are arrays built into Csound. 
For example, if you had an N sized array of audio signals, and an N sized array of cutoff frequencies and resonance frequencies. Instead of writing the opcode out N many times, you could simply pass the arrays into a filter opcode and you would implicitly receive N many audio signals. Similarly if you had a single audio signal as input but an N sized array of cutoffs and resonances frequencies you would also implicitly get back an N sized audio array. 
As the processing is done in parallel perhaps there could also be room for optimisations, I know open cl could come in handy there in the future.
I know at the moment that this can be done manually by just rewriting opcodes to support this feature, would it be possible to add this to Csound to support existing opcodes? If thats a crazy idea, or something like this already exists sorry for my ignorance :)
Ed



------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It is something I have been discussing with Steven, where opcodes could be passed in to a “parallel” and
a “serial” opcode and this would spawn them. We thought that if we had an opcode type, that would be 
a good possibility.

Of course, it is possible to do parallel and serial connections like that with recursive UDOs. But this system
would facilitate things a bit.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 6 Aug 2014, at 14:49, Edward Costello  wrote:

> Hi,
> 
> I was just thinking that having the ability to create a bank of opcodes using one line would be very handy now that there are arrays built into Csound. 
> For example, if you had an N sized array of audio signals, and an N sized array of cutoff frequencies and resonance frequencies. Instead of writing the opcode out N many times, you could simply pass the arrays into a filter opcode and you would implicitly receive N many audio signals. Similarly if you had a single audio signal as input but an N sized array of cutoffs and resonances frequencies you would also implicitly get back an N sized audio array. 
> As the processing is done in parallel perhaps there could also be room for optimisations, I know open cl could come in handy there in the future.
> I know at the moment that this can be done manually by just rewriting opcodes to support this feature, would it be possible to add this to Csound to support existing opcodes? If thats a crazy idea, or something like this already exists sorry for my ignorance :)
> Ed
> 
> 
> 
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls. 
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I had an idea this morning when reading Ed's email. One thing we could
do is think of a map opcode that would take in an opcode name, a list
of array of args, then return an array of the outputs from the opcode.
So something like:

ifreqs[] = array(440, 880, 1320, 1760)
iamps 0.5

asigs[] = map(oscili, ifreqs, iamps)

The map operator would read in the args. If a scalar is given, that
arg would be used for every opcode instantiation.  If an array is
given, it will use the values for each opcode.  What would happen then
is the map opcode would take on the same characteristics as the opcode
passed in, in terms of i-time only, k-time only, or both.

Internally, map would have to do type checking.  It would have to look
at the types passed in, then search for an opcode that matches those
types, then check if the out type would match up. In this case, it'd
have to lookup oscili, see if there is a type that takes in "ii" for
in-args, then check if a[] is the out type.  If all is good, allocate
a linked list of opcode instances.

There is a problem though. We'd have to com up with a rule here as to
how the array values are used.  For example, let's say we have:

asigs[] = ...some set of signals...
asigs2[] = map(filter, asigs)

we have two options.  One is to assign the inputs to each filter
instance directly to the location in memory of the asigs data block.
That seems problematic if later code reassigns the asigs array.  The
other is that map would have to copy by value each time from asigs
into arg space for each filter instance.  That wouldn't be too bad to
implement (similar to what we do for UDO invokations).

The one thing that is the kicker in all this is that the parser needs
changes to support all this.  At this point, we have enough patches
and hacks to the parser that, IMO, we need to revise the parser a bit
(hence the proposed Parser3 branch).  I think this use case should
definitely be a requirement for the release of Parser3, and I plan to
develop against this use case once the Parser3 stuff is going.
(Hopefully soon, I got stuck in removing xincod_str the other day, but
I think I'll have a work around that should work for now.)

steven

On Wed, Aug 6, 2014 at 10:28 AM, Victor Lazzarini
 wrote:
> It is something I have been discussing with Steven, where opcodes could be passed in to a “parallel” and
> a “serial” opcode and this would spawn them. We thought that if we had an opcode type, that would be
> a good possibility.
>
> Of course, it is possible to do parallel and serial connections like that with recursive UDOs. But this system
> would facilitate things a bit.
>
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 6 Aug 2014, at 14:49, Edward Costello  wrote:
>
>> Hi,
>>
>> I was just thinking that having the ability to create a bank of opcodes using one line would be very handy now that there are arrays built into Csound.
>> For example, if you had an N sized array of audio signals, and an N sized array of cutoff frequencies and resonance frequencies. Instead of writing the opcode out N many times, you could simply pass the arrays into a filter opcode and you would implicitly receive N many audio signals. Similarly if you had a single audio signal as input but an N sized array of cutoffs and resonances frequencies you would also implicitly get back an N sized audio array.
>> As the processing is done in parallel perhaps there could also be room for optimisations, I know open cl could come in handy there in the future.
>> I know at the moment that this can be done manually by just rewriting opcodes to support this feature, would it be possible to add this to Csound to support existing opcodes? If thats a crazy idea, or something like this already exists sorry for my ignorance :)
>> Ed
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Infragistics Professional
> Build stunning WinForms apps today!
> Reboot your WinForms applications with our WinForms controls.
> Build a bridge from your legacy apps to the future.
> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound