i am still thinking about the role of UDOs and their integration into
csound. i personally like the idea that UDOs are in a way considered as
a part of csound (as victor said about the implementation of some
t-variable tools).

but i think we should then ensure that there is a way of testing which
is comparable to the usual csound code. perhaps there could be a group
of UDO developers which
1) tests all UDOs and examples and
2) gives some feedback to the authors if necessary?

what do others think?

	joachim

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It's a good idea. I think it could start by people looking at the UDO database and making sure all that is there works.

Victor
On 25 Apr 2012, at 12:39, joachim heintz wrote:

> i am still thinking about the role of UDOs and their integration into
> csound. i personally like the idea that UDOs are in a way considered as
> a part of csound (as victor said about the implementation of some
> t-variable tools).
> 
> but i think we should then ensure that there is a way of testing which
> is comparable to the usual csound code. perhaps there could be a group
> of UDO developers which
> 1) tests all UDOs and examples and
> 2) gives some feedback to the authors if necessary?
> 
> what do others think?
> 
> 	joachim
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think we need better integration of UDOs in general. It would be
nice if UDOs were just like regular loadable plugins. Ideally all UDOs
would live inside the opcodeDir and could be loaded like any other
opcode. However, I know that this is rather tricky to implement, so
the next best thing would be a for Csound to search opcodeDir for UDOs
when #includes are used. For example:

sr = 44100
ksmps = 32

;SigGens includes all the SigGen UDOs
#include "SigGens.udo"

instr 1
a1 inch 1
arev SigRev a1, 1
out arev
endin

With this in place it makes the instrument portable without users
having to modify the include path. Organising UDOs into larger
collections would also help keep things simple. What do people think?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

I agree that UDOs can provide a great facility this way. What you
propose can currently be done by specifying INCDIR, but maybe it's
worth having a dedicated UDODIR?

Also distributing the UDOs in a consistent and simple manner would be
ideal (in such a way that if I use a "standard" UDO in any platform,
the csd will still work on any other). Your idea of bundling together
UDOs by category sounds good, that way you include a certain file and
it brings a set of related opcodes. That way you don't have to include
all UDOs from a single file, but neither do you have to include every
single one individually.

To avoid confusion maybe something like namespaces might be introduced for UDOs?

Cheers,
Andrés

On Wed, Apr 25, 2012 at 1:12 PM, Rory Walsh  wrote:
> I think we need better integration of UDOs in general. It would be
> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
> would live inside the opcodeDir and could be loaded like any other
> opcode. However, I know that this is rather tricky to implement, so
> the next best thing would be a for Csound to search opcodeDir for UDOs
> when #includes are used. For example:
>
> sr = 44100
> ksmps = 32
>
> ;SigGens includes all the SigGen UDOs
> #include "SigGens.udo"
>
> instr 1
> a1 inch 1
> arev SigRev a1, 1
> out arev
> endin
>
> With this in place it makes the instrument portable without users
> having to modify the include path. Organising UDOs into larger
> collections would also help keep things simple. What do people think?
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/

It would be worthwhile to look at the Python model for this. You can
import an entire module, select only what you need, handles
namespaces, and even lets you rename things on import.

import filters
from filters import lowpass
from filters import lowpass as mylowpass
import filters as f

Personally, I would love it if Csound did this with opcodes in general.

Best,
Jake

On Wed, Apr 25, 2012 at 6:06 AM, Andres Cabrera  wrote:
> Hi,
>
> I agree that UDOs can provide a great facility this way. What you
> propose can currently be done by specifying INCDIR, but maybe it's
> worth having a dedicated UDODIR?
>
> Also distributing the UDOs in a consistent and simple manner would be
> ideal (in such a way that if I use a "standard" UDO in any platform,
> the csd will still work on any other). Your idea of bundling together
> UDOs by category sounds good, that way you include a certain file and
> it brings a set of related opcodes. That way you don't have to include
> all UDOs from a single file, but neither do you have to include every
> single one individually.
>
> To avoid confusion maybe something like namespaces might be introduced for UDOs?
>
> Cheers,
> Andrés
>
> On Wed, Apr 25, 2012 at 1:12 PM, Rory Walsh  wrote:
>> I think we need better integration of UDOs in general. It would be
>> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
>> would live inside the opcodeDir and could be loaded like any other
>> opcode. However, I know that this is rather tricky to implement, so
>> the next best thing would be a for Csound to search opcodeDir for UDOs
>> when #includes are used. For example:
>>
>> sr = 44100
>> ksmps = 32
>>
>> ;SigGens includes all the SigGen UDOs
>> #include "SigGens.udo"
>>
>> instr 1
>> a1 inch 1
>> arev SigRev a1, 1
>> out arev
>> endin
>>
>> With this in place it makes the instrument portable without users
>> having to modify the include path. Organising UDOs into larger
>> collections would also help keep things simple. What do people think?
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
codehop.com | #code #art #music

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listin

Namespaces are a good idea.
I would also like to see if a facility for loading UDOs from remote URLs might be a good idea.

Victor
On 25 Apr 2012, at 14:06, Andres Cabrera wrote:

> Hi,
> 
> I agree that UDOs can provide a great facility this way. What you
> propose can currently be done by specifying INCDIR, but maybe it's
> worth having a dedicated UDODIR?
> 
> Also distributing the UDOs in a consistent and simple manner would be
> ideal (in such a way that if I use a "standard" UDO in any platform,
> the csd will still work on any other). Your idea of bundling together
> UDOs by category sounds good, that way you include a certain file and
> it brings a set of related opcodes. That way you don't have to include
> all UDOs from a single file, but neither do you have to include every
> single one individually.
> 
> To avoid confusion maybe something like namespaces might be introduced for UDOs?
> 
> Cheers,
> Andrés
> 
> On Wed, Apr 25, 2012 at 1:12 PM, Rory Walsh  wrote:
>> I think we need better integration of UDOs in general. It would be
>> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
>> would live inside the opcodeDir and could be loaded like any other
>> opcode. However, I know that this is rather tricky to implement, so
>> the next best thing would be a for Csound to search opcodeDir for UDOs
>> when #includes are used. For example:
>> 
>> sr = 44100
>> ksmps = 32
>> 
>> ;SigGens includes all the SigGen UDOs
>> #include "SigGens.udo"
>> 
>> instr 1
>> a1 inch 1
>> arev SigRev a1, 1
>> out arev
>> endin
>> 
>> With this in place it makes the instrument portable without users
>> having to modify the include path. Organising UDOs into larger
>> collections would also help keep things simple. What do people think?
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Given that a UDO can contain arbitrary code (python or lua, or even
shell commands), loading them from a URL is very definitely a very bad
idea security wise.

I think it is better to provide a UDO bundle that one can download regularly.

On Wed, Apr 25, 2012 at 10:14, Victor Lazzarini
 wrote:
>
> Namespaces are a good idea.
> I would also like to see if a facility for loading UDOs from remote URLs
> might be a good idea.
>
> Victor
> On 25 Apr 2012, at 14:06, Andres Cabrera wrote:
>
> > Hi,
> >
> > I agree that UDOs can provide a great facility this way. What you
> > propose can currently be done by specifying INCDIR, but maybe it's
> > worth having a dedicated UDODIR?
> >
> > Also distributing the UDOs in a consistent and simple manner would be
> > ideal (in such a way that if I use a "standard" UDO in any platform,
> > the csd will still work on any other). Your idea of bundling together
> > UDOs by category sounds good, that way you include a certain file and
> > it brings a set of related opcodes. That way you don't have to include
> > all UDOs from a single file, but neither do you have to include every
> > single one individually.
> >
> > To avoid confusion maybe something like namespaces might be introduced
> > for UDOs?
> >
> > Cheers,
> > Andrés
> >
> > On Wed, Apr 25, 2012 at 1:12 PM, Rory Walsh  wrote:
> >> I think we need better integration of UDOs in general. It would be
> >> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
> >> would live inside the opcodeDir and could be loaded like any other
> >> opcode. However, I know that this is rather tricky to implement, so
> >> the next best thing would be a for Csound to search opcodeDir for UDOs
> >> when #includes are used. For example:
> >>
> >> sr = 44100
> >> ksmps = 32
> >>
> >> ;SigGens includes all the SigGen UDOs
> >> #include "SigGens.udo"
> >>
> >> instr 1
> >> a1 inch 1
> >> arev SigRev a1, 1
> >> out arev
> >> endin
> >>
> >> With this in place it makes the instrument portable without users
> >> having to modify the include path. Organising UDOs into larger
> >> collections would also help keep things simple. What do people think?
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> >> Discussions
> >> will include endpoint security, mobile security and the latest in
> >> malware
> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond.
> > Discussions
> > will include endpoint security, mobile security and the latest in
> > malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel




--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https:/

On Wed, Apr 25, 2012 at 10:06, Andres Cabrera  wrote:
> I agree that UDOs can provide a great facility this way. What you
> propose can currently be done by specifying INCDIR, but maybe it's
> worth having a dedicated UDODIR?

Maybe the current path variables could be redesigned similarly to how
the compiler manages its paths:

1. Csound as a hard-compiled list of paths to look in (probably just
one, defined at build time).
2. Env vars work with : separated paths, just like the PATH envvar.
3. Flags --add-path:{OPCODEDIR,UDODIR,...} could be added, that can be
called multiple times, appending to the list of paths.

A higher number here means a higher priority: paths on the command
line take precedence over paths on the environment over the predefined
paths. If a module exists twice, then only the one from the highest
priority path is loaded.

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Do the developers of installers already set the INCDIR variable? If
not could they possibly set/add a folder called UDO in which all the
UDOs from the database can be placed? This would get us over the first
hurdle of including the UDO database, and making the using of them
consistent across platforms.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I doubt I can (as debian package maintainer) alter the environment of
all users. That is why I am proposing chaning from a single path to a
path list: it would be possible to specify sensible defaults at build
time (for those of us that know where we install things).

On Wed, Apr 25, 2012 at 13:14, Rory Walsh  wrote:
> Do the developers of installers already set the INCDIR variable? If
> not could they possibly set/add a folder called UDO in which all the
> UDOs from the database can be placed? This would get us over the first
> hurdle of including the UDO database, and making the using of them
> consistent across platforms.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hmm, it seems I the env vars are already treated like path lists.
Please ignore what I said, and sorry for the noise.

On Wed, Apr 25, 2012 at 13:37, Felipe Sateler  wrote:
> I doubt I can (as debian package maintainer) alter the environment of
> all users. That is why I am proposing chaning from a single path to a
> path list: it would be possible to specify sensible defaults at build
> time (for those of us that know where we install things).
>
> On Wed, Apr 25, 2012 at 13:14, Rory Walsh  wrote:
>> Do the developers of installers already set the INCDIR variable? If
>> not could they possibly set/add a folder called UDO in which all the
>> UDOs from the database can be placed? This would get us over the first
>> hurdle of including the UDO database, and making the using of them
>> consistent across platforms.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hmm - other than regular opcodes udos can easily be rewritten. the
syntax may change because some additions or any feedback from users.
so we may need a version control, too?
	j


Am 25.04.2012 14:12, schrieb Rory Walsh:
> I think we need better integration of UDOs in general. It would be
> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
> would live inside the opcodeDir and could be loaded like any other
> opcode. However, I know that this is rather tricky to implement, so
> the next best thing would be a for Csound to search opcodeDir for UDOs
> when #includes are used. For example:
> 
> sr = 44100
> ksmps = 32
> 
> ;SigGens includes all the SigGen UDOs
> #include "SigGens.udo"
> 
> instr 1
> a1 inch 1
> arev SigRev a1, 1
> out arev
> endin
> 
> With this in place it makes the instrument portable without users
> having to modify the include path. Organising UDOs into larger
> collections would also help keep things simple. What do people think?
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

how could namespaces be introduced?
best -
	j

Am 25.04.2012 15:14, schrieb Victor Lazzarini:
> Namespaces are a good idea.
> I would also like to see if a facility for loading UDOs from remote URLs might be a good idea.
> 
> Victor
> On 25 Apr 2012, at 14:06, Andres Cabrera wrote:
> 
>> Hi,
>>
>> I agree that UDOs can provide a great facility this way. What you
>> propose can currently be done by specifying INCDIR, but maybe it's
>> worth having a dedicated UDODIR?
>>
>> Also distributing the UDOs in a consistent and simple manner would be
>> ideal (in such a way that if I use a "standard" UDO in any platform,
>> the csd will still work on any other). Your idea of bundling together
>> UDOs by category sounds good, that way you include a certain file and
>> it brings a set of related opcodes. That way you don't have to include
>> all UDOs from a single file, but neither do you have to include every
>> single one individually.
>>
>> To avoid confusion maybe something like namespaces might be introduced for UDOs?
>>
>> Cheers,
>> Andrés
>>
>> On Wed, Apr 25, 2012 at 1:12 PM, Rory Walsh  wrote:
>>> I think we need better integration of UDOs in general. It would be
>>> nice if UDOs were just like regular loadable plugins. Ideally all UDOs
>>> would live inside the opcodeDir and could be loaded like any other
>>> opcode. However, I know that this is rather tricky to implement, so
>>> the next best thing would be a for Csound to search opcodeDir for UDOs
>>> when #includes are used. For example:
>>>
>>> sr = 44100
>>> ksmps = 32
>>>
>>> ;SigGens includes all the SigGen UDOs
>>> #include "SigGens.udo"
>>>
>>> instr 1
>>> a1 inch 1
>>> arev SigRev a1, 1
>>> out arev
>>> endin
>>>
>>> With this in place it makes the instrument portable without users
>>> having to modify the include path. Organising UDOs into larger
>>> collections would also help keep things simple. What do people think?
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://l

I'm not sure Joachim. Version control is nice but I think it should be
down to the authors of the UDOs to maintain/develop? Plus with 100%
backward compatibility guaranteed once a UDO works, it will always
work(how cool is that!).

Of course the great thing about this is that all the expert Csound
users who don't code in c/c++ can now contribute code directly to
Csound distributions. Code written by you, Iain, Piemen, etc, etc,
should be distributed with Csound. And as teachers we can encourage
our own students to contribute too. I believe that too many amazing
Csound instruments are just sitting idle on hard drives across the
world.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Apologies, I obviously meant "Peiman"...

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net