There was a request for automatic loading of UDOs (from Rory I think).
As a result I now have code that looks for the environment variable
CS_UDO_DIR to identify a location and includes all files in it ending
in .udo

Questions:
1: is this the correct/best envvar to use?

2: Should it also include .inc files or everything?

Also this code uses #include before reading the orchestra which might
limit the utility.  And there is no ordering control over the
#includes.  If that was important it might be possible to address.

==John ffitch

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
it automatically look in the same directory as the .csd file? To avoid
the use of includes, could Csound not search the UDO_DIR on startup
for all .udo files and simply compile them on the fly in instr0 before
the score runs? Of course there is little point of compiling them all
if they are not needed, so I'm not sure how to best address that. To
be honest, if we had a new tag called  that could be
placed at the bottom of the csd file I'd be happy to just use that.
The problem I have with the current system is that it usually scares
the bejisus out of students when they see these complex UDOs before
instruments definitions. Before doing any more work on this maybe we
should hear from others and see what they think?

On 12 November 2013 10:02, john ffitch  wrote:
> There was a request for automatic loading of UDOs (from Rory I think).
> As a result I now have code that looks for the environment variable
> CS_UDO_DIR to identify a location and includes all files in it ending
> in .udo
>
> Questions:
> 1: is this the correct/best envvar to use?
>
> 2: Should it also include .inc files or everything?
>
> Also this code uses #include before reading the orchestra which might
> limit the utility.  And there is no ordering control over the
> #includes.  If that was important it might be possible to address.
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I also agree this should not be enabled by default, maybe a preprocessor line
can be used?

#loadudos  


On 12 Nov 2013, at 10:31, Rory Walsh  wrote:

> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
> it automatically look in the same directory as the .csd file? To avoid
> the use of includes, could Csound not search the UDO_DIR on startup
> for all .udo files and simply compile them on the fly in instr0 before
> the score runs? Of course there is little point of compiling them all
> if they are not needed, so I'm not sure how to best address that. To
> be honest, if we had a new tag called  that could be
> placed at the bottom of the csd file I'd be happy to just use that.
> The problem I have with the current system is that it usually scares
> the bejisus out of students when they see these complex UDOs before
> instruments definitions. Before doing any more work on this maybe we
> should hear from others and see what they think?
> 
> On 12 November 2013 10:02, john ffitch  wrote:
>> There was a request for automatic loading of UDOs (from Rory I think).
>> As a result I now have code that looks for the environment variable
>> CS_UDO_DIR to identify a location and includes all files in it ending
>> in .udo
>> 
>> Questions:
>> 1: is this the correct/best envvar to use?
>> 
>> 2: Should it also include .inc files or everything?
>> 
>> Also this code uses #include before reading the orchestra which might
>> limit the utility.  And there is no ordering control over the
>> #includes.  If that was important it might be possible to address.
>> 
>> ==John ffitch
>> 
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What do you think about an additional  option? f I could hide
all the UDO stuff at the end of the csd file it would be great, and
one could ensure that all UDOs stay within the .csd file, which is of
course one of the major advantages to the current system.

On 12 November 2013 11:04, Victor Lazzarini  wrote:
> I also agree this should not be enabled by default, maybe a preprocessor line
> can be used?
>
> #loadudos  
>
>
> On 12 Nov 2013, at 10:31, Rory Walsh  wrote:
>
>> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
>> it automatically look in the same directory as the .csd file? To avoid
>> the use of includes, could Csound not search the UDO_DIR on startup
>> for all .udo files and simply compile them on the fly in instr0 before
>> the score runs? Of course there is little point of compiling them all
>> if they are not needed, so I'm not sure how to best address that. To
>> be honest, if we had a new tag called  that could be
>> placed at the bottom of the csd file I'd be happy to just use that.
>> The problem I have with the current system is that it usually scares
>> the bejisus out of students when they see these complex UDOs before
>> instruments definitions. Before doing any more work on this maybe we
>> should hear from others and see what they think?
>>
>> On 12 November 2013 10:02, john ffitch  wrote:
>>> There was a request for automatic loading of UDOs (from Rory I think).
>>> As a result I now have code that looks for the environment variable
>>> CS_UDO_DIR to identify a location and includes all files in it ending
>>> in .udo
>>>
>>> Questions:
>>> 1: is this the correct/best envvar to use?
>>>
>>> 2: Should it also include .inc files or everything?
>>>
>>> Also this code uses #include before reading the orchestra which might
>>> limit the utility.  And there is no ordering control over the
>>> #includes.  If that was important it might be possible to address.
>>>
>>> ==John ffitch
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models. Explore
>>> techniques for threading, error checking, porting, and tuning. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and register
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Only if this is in addition to having UDOs in the orchestra body (otherwise we will break compatibility).
But if you want to hide UDOs, you should use #include (or any proposed method to load all UDOs).

Victor
On 12 Nov 2013, at 11:11, Rory Walsh  wrote:

> What do you think about an additional  option? f I could hide
> all the UDO stuff at the end of the csd file it would be great, and
> one could ensure that all UDOs stay within the .csd file, which is of
> course one of the major advantages to the current system.
> 
> On 12 November 2013 11:04, Victor Lazzarini  wrote:
>> I also agree this should not be enabled by default, maybe a preprocessor line
>> can be used?
>> 
>> #loadudos  
>> 
>> 
>> On 12 Nov 2013, at 10:31, Rory Walsh  wrote:
>> 
>>> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
>>> it automatically look in the same directory as the .csd file? To avoid
>>> the use of includes, could Csound not search the UDO_DIR on startup
>>> for all .udo files and simply compile them on the fly in instr0 before
>>> the score runs? Of course there is little point of compiling them all
>>> if they are not needed, so I'm not sure how to best address that. To
>>> be honest, if we had a new tag called  that could be
>>> placed at the bottom of the csd file I'd be happy to just use that.
>>> The problem I have with the current system is that it usually scares
>>> the bejisus out of students when they see these complex UDOs before
>>> instruments definitions. Before doing any more work on this maybe we
>>> should hear from others and see what they think?
>>> 
>>> On 12 November 2013 10:02, john ffitch  wrote:
>>>> There was a request for automatic loading of UDOs (from Rory I think).
>>>> As a result I now have code that looks for the environment variable
>>>> CS_UDO_DIR to identify a location and includes all files in it ending
>>>> in .udo
>>>> 
>>>> Questions:
>>>> 1: is this the correct/best envvar to use?
>>>> 
>>>> 2: Should it also include .inc files or everything?
>>>> 
>>>> Also this code uses #include before reading the orchestra which might
>>>> limit the utility.  And there is no ordering control over the
>>>> #includes.  If that was important it might be possible to address.
>>>> 
>>>> ==John ffitch
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> November Webinars for C, C++, Fortran Developers
>>>> Accelerate application performance with scalable programming models. Explore
>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models. Explore
>>> techniques for threading, error checking, porting, and tuning. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and register
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, it would be in addition. It's nice to have them included in the
files, but not so nice that they have to be in instr0 space. With an
additional csUDO section, I could provide my students with a basic
.csd file, containing a number of utility UDOs at the bottom. I could
even set it up to be the default .csd file used by CsoundQT or
WinXound when students start a new file.

On 12 November 2013 11:47, Victor Lazzarini  wrote:
> Only if this is in addition to having UDOs in the orchestra body (otherwise we will break compatibility).
> But if you want to hide UDOs, you should use #include (or any proposed method to load all UDOs).
>
> Victor
> On 12 Nov 2013, at 11:11, Rory Walsh  wrote:
>
>> What do you think about an additional  option? f I could hide
>> all the UDO stuff at the end of the csd file it would be great, and
>> one could ensure that all UDOs stay within the .csd file, which is of
>> course one of the major advantages to the current system.
>>
>> On 12 November 2013 11:04, Victor Lazzarini  wrote:
>>> I also agree this should not be enabled by default, maybe a preprocessor line
>>> can be used?
>>>
>>> #loadudos  
>>>
>>>
>>> On 12 Nov 2013, at 10:31, Rory Walsh  wrote:
>>>
>>>> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
>>>> it automatically look in the same directory as the .csd file? To avoid
>>>> the use of includes, could Csound not search the UDO_DIR on startup
>>>> for all .udo files and simply compile them on the fly in instr0 before
>>>> the score runs? Of course there is little point of compiling them all
>>>> if they are not needed, so I'm not sure how to best address that. To
>>>> be honest, if we had a new tag called  that could be
>>>> placed at the bottom of the csd file I'd be happy to just use that.
>>>> The problem I have with the current system is that it usually scares
>>>> the bejisus out of students when they see these complex UDOs before
>>>> instruments definitions. Before doing any more work on this maybe we
>>>> should hear from others and see what they think?
>>>>
>>>> On 12 November 2013 10:02, john ffitch  wrote:
>>>>> There was a request for automatic loading of UDOs (from Rory I think).
>>>>> As a result I now have code that looks for the environment variable
>>>>> CS_UDO_DIR to identify a location and includes all files in it ending
>>>>> in .udo
>>>>>
>>>>> Questions:
>>>>> 1: is this the correct/best envvar to use?
>>>>>
>>>>> 2: Should it also include .inc files or everything?
>>>>>
>>>>> Also this code uses #include before reading the orchestra which might
>>>>> limit the utility.  And there is no ordering control over the
>>>>> #includes.  If that was important it might be possible to address.
>>>>>
>>>>> ==John ffitch
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> November Webinars for C, C++, Fortran Developers
>>>>> Accelerate application performance with scalable programming models. Explore
>>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> November Webinars for C, C++, Fortran Developers
>>>> Accelerate application performance with scalable programming models. Explore
>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models. Explore
>>> techniques for threading, error checking, porting, and tuning. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and register
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

i like the idea of an additional  tag which could be placed at 
the end of the whole .csd file. i agree it would make the code much more 
readable for complex udos.
best -
	joachim


Am 12.11.2013 12:57, schrieb Rory Walsh:
> Yes, it would be in addition. It's nice to have them included in the
> files, but not so nice that they have to be in instr0 space. With an
> additional csUDO section, I could provide my students with a basic
> .csd file, containing a number of utility UDOs at the bottom. I could
> even set it up to be the default .csd file used by CsoundQT or
> WinXound when students start a new file.
>
> On 12 November 2013 11:47, Victor Lazzarini  wrote:
>> Only if this is in addition to having UDOs in the orchestra body (otherwise we will break compatibility).
>> But if you want to hide UDOs, you should use #include (or any proposed method to load all UDOs).
>>
>> Victor
>> On 12 Nov 2013, at 11:11, Rory Walsh  wrote:
>>
>>> What do you think about an additional  option? f I could hide
>>> all the UDO stuff at the end of the csd file it would be great, and
>>> one could ensure that all UDOs stay within the .csd file, which is of
>>> course one of the major advantages to the current system.
>>>
>>> On 12 November 2013 11:04, Victor Lazzarini  wrote:
>>>> I also agree this should not be enabled by default, maybe a preprocessor line
>>>> can be used?
>>>>
>>>> #loadudos  
>>>>
>>>>
>>>> On 12 Nov 2013, at 10:31, Rory Walsh  wrote:
>>>>
>>>>> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
>>>>> it automatically look in the same directory as the .csd file? To avoid
>>>>> the use of includes, could Csound not search the UDO_DIR on startup
>>>>> for all .udo files and simply compile them on the fly in instr0 before
>>>>> the score runs? Of course there is little point of compiling them all
>>>>> if they are not needed, so I'm not sure how to best address that. To
>>>>> be honest, if we had a new tag called  that could be
>>>>> placed at the bottom of the csd file I'd be happy to just use that.
>>>>> The problem I have with the current system is that it usually scares
>>>>> the bejisus out of students when they see these complex UDOs before
>>>>> instruments definitions. Before doing any more work on this maybe we
>>>>> should hear from others and see what they think?
>>>>>
>>>>> On 12 November 2013 10:02, john ffitch  wrote:
>>>>>> There was a request for automatic loading of UDOs (from Rory I think).
>>>>>> As a result I now have code that looks for the environment variable
>>>>>> CS_UDO_DIR to identify a location and includes all files in it ending
>>>>>> in .udo
>>>>>>
>>>>>> Questions:
>>>>>> 1: is this the correct/best envvar to use?
>>>>>>
>>>>>> 2: Should it also include .inc files or everything?
>>>>>>
>>>>>> Also this code uses #include before reading the orchestra which might
>>>>>> limit the utility.  And there is no ordering control over the
>>>>>> #includes.  If that was important it might be possible to address.
>>>>>>
>>>>>> ==John ffitch
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>> Accelerate application performance with scalable programming models. Explore
>>>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> November Webinars for C, C++, Fortran Developers
>>>>> Accelerate application performance with scalable programming models. Explore
>>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> November Webinars for C, C++, Fortran Developers
>>>> Accelerate application performance with scalable programming models. Explore
>>>> techniques for threading, error checking, porting, and tuning. Get the most
>>>> from the latest Intel processors and coprocessors. See abstracts and register
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models. Explore
>>> techniques for threading, error checking, porting, and tuning. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and register
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree, one must be able to continue to use the system as is, be it
with include's, or inline code. I think an environment variable is
also a nice touch. And a dedicated csUDO section would be the icing on
the cake ;)

On 12 November 2013 15:09, Richard Henninger  wrote:
> Why not make sure to permit #include statements along with inline UDO code
> in a new  section to get the best of both worlds?
>
> I presume that having the #include for UDO’s isolated within their own
>  section would handle the timing issue that was worrying john by
> permitting their internal structures to be built at their optimal moment
> during compilation independently of building other compiler structures.
> Presumably, non-UDO code in this section would be a compiler error whether
> inline or included.
>
> This way, you can combine libraries and inline code as appropriate for a
> given piece.
>
> Richard Henninger
> richard@rghmusic.com
>
> From: joachim heintz
> Sent: Tuesday, November 12, 2013 8:27 AM
> To: Developer discussions
>
> i like the idea of an additional  tag which could be placed at
> the end of the whole .csd file. i agree it would make the code much more
> readable for complex udos.
> best -
>  joachim
>
>
> Am 12.11.2013 12:57, schrieb Rory Walsh:
>> Yes, it would be in addition. It's nice to have them included in the
>> files, but not so nice that they have to be in instr0 space. With an
>> additional csUDO section, I could provide my students with a basic
>> .csd file, containing a number of utility UDOs at the bottom. I could
>> even set it up to be the default .csd file used by CsoundQT or
>> WinXound when students start a new file.
>>
>> On 12 November 2013 11:47, Victor Lazzarini 
>> wrote:
>>> Only if this is in addition to having UDOs in the orchestra body
>>> (otherwise we will break compatibility).
>>> But if you want to hide UDOs, you should use #include (or any proposed
>>> method to load all UDOs).
>>>
>>> Victor
>>> On 12 Nov 2013, at 11:11, Rory Walsh  wrote:
>>>
>>>> What do you think about an additional  option? f I could hide
>>>> all the UDO stuff at the end of the csd file it would be great, and
>>>> one could ensure that all UDOs stay within the .csd file, which is of
>>>> course one of the major advantages to the current system.
>>>>
>>>> On 12 November 2013 11:04, Victor Lazzarini 
>>>> wrote:
>>>>> I also agree this should not be enabled by default, maybe a
>>>>> preprocessor line
>>>>> can be used?
>>>>>
>>>>> #loadudos  
>>>>>
>>>>>
>>>>> On 12 Nov 2013, at 10:31, Rory Walsh  wrote:
>>>>>
>>>>>> Hi John, thanks for looking into this. If CS_UDO_DIR is not set, will
>>>>>> it automatically look in the same directory as the .csd file? To avoid
>>>>>> the use of includes, could Csound not search the UDO_DIR on startup
>>>>>> for all .udo files and simply compile them on the fly in instr0 before
>>>>>> the score runs? Of course there is little point of compiling them all
>>>>>> if they are not needed, so I'm not sure how to best address that. To
>>>>>> be honest, if we had a new tag called  that could be
>>>>>> placed at the bottom of the csd file I'd be happy to just use that.
>>>>>> The problem I have with the current system is that it usually scares
>>>>>> the bejisus out of students when they see these complex UDOs before
>>>>>> instruments definitions. Before doing any more work on this maybe we
>>>>>> should hear from others and see what they think?
>>>>>>
>>>>>> On 12 November 2013 10:02, john ffitch  wrote:
>>>>>>> There was a request for automatic loading of UDOs (from Rory I
>>>>>>> think).
>>>>>>> As a result I now have code that looks for the environment variable
>>>>>>> CS_UDO_DIR to identify a location and includes all files in it ending
>>>>>>> in .udo
>>>>>>>
>>>>>>> Questions:
>>>>>>> 1: is this the correct/best envvar to use?
>>>>>>>
>>>>>>> 2: Should it also include .inc files or everything?
>>>>>>>
>>>>>>> Also this code uses #include before reading the orchestra which might
>>>>>>> limit the utility.  And there is no ordering control over the
>>>>>>> #includes.  If that was important it might be possible to address.
>>>>>>>
>>>>>>> ==John ffitch
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>> Accelerate application performance with scalable programming models.
>>>>>>> Explore
>>>>>>> techniques for threading, error checking, porting, and tuning. Get
>>>>>>> the most
>>>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>>>> register
>>>>>>>
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>> Accelerate application performance with scalable programming models.
>>>>>> Explore
>>>>>> techniques for threading, error checking, porting, and tuning. Get the
>>>>>> most
>>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>>> register
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> November Webinars for C, C++, Fortran Developers
>>>>> Accelerate application performance with scalable programming models.
>>>>> Explore
>>>>> techniques for threading, error checking, porting, and tuning. Get the
>>>>> most
>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>> register
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> November Webinars for C, C++, Fortran Developers
>>>> Accelerate application performance with scalable programming models.
>>>> Explore
>>>> techniques for threading, error checking, porting, and tuning. Get the
>>>> most
>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>> register
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models.
>>> Explore
>>> techniques for threading, error checking, porting, and tuning. Get the
>>> most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks for your feedback Steven. I can see your point about the order
of processing. I guess it could lead to some confusion. However, I'd
rather not have to teach project management to my first year students
who have zero experience with programming :) I'd love to use UDOs more
in my teaching, but without #includes they bloat orchestra sections to
the extent that it's often hard to find instrument definitions. How
about something like this which makes it explicit that we are
inserting code from another section of the Csd file:



using CsUDO

instr 1
a1 Oscil 1, 200
out a1
endin



i1 0 10


opcode Oscil, a, kk
kamp, kcps      xin
a1      vco2 kamp, kcps
        xout a1
        endop



I'm not sure about the word 'using', as you might already have ideas
for that keyword with regards to future developments, but 'import',
'expand', or 'inline' might do just a well. Do you still see too many
issues with the above solution?

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Ok, message received! I'll just use '#include' from now on. I'm very
glad to have had a discussion about it, and the last thing I want is
for developers to spend time on certain things when there are bigger
fish to fry. What's that I hear... did someone mention user defined
data types :)


On 12 November 2013 17:54, Michael Gogins  wrote:
> I basically agree with Steven.
>
> You could encourage your students to use CsoundQt, which enables one to move
> quickly from one element of a csd to another with ease.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 12, 2013 at 12:01 PM, Rory Walsh  wrote:
>>
>> Thanks for your feedback Steven. I can see your point about the order
>> of processing. I guess it could lead to some confusion. However, I'd
>> rather not have to teach project management to my first year students
>> who have zero experience with programming :) I'd love to use UDOs more
>> in my teaching, but without #includes they bloat orchestra sections to
>> the extent that it's often hard to find instrument definitions. How
>> about something like this which makes it explicit that we are
>> inserting code from another section of the Csd file:
>>
>> 
>> 
>> using CsUDO
>>
>> instr 1
>> a1 Oscil 1, 200
>> out a1
>> endin
>>
>> 
>> 
>> i1 0 10
>> 
>> 
>> opcode Oscil, a, kk
>> kamp, kcps      xin
>> a1      vco2 kamp, kcps
>>         xout a1
>>         endop
>> 
>> 
>>
>> I'm not sure about the word 'using', as you might already have ideas
>> for that keyword with regards to future developments, but 'import',
>> 'expand', or 'inline' might do just a well. Do you still see too many
>> issues with the above solution?
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net