I have looked into the Loris situation and things are much clearer  
now. Kelly Fitz has been very helpful promptly replying to my e-mails.

What happens is that the Loris library now has built-in support for  
Csound as a plugin. So now we do not build the opcodes separately and  
then link to libloris. Kelly has included the code for the opcodes  
inside it so nothing else is needed. In other words: if you build  
Loris with the csound option (enabled by making configure find the  
csound headers), it will include the opcodes.To use them you just have  
to point --opcode-lib to your installed libloris.*

This means probably means that the opcodes in Csound CVS are probably  
out-of-date and should be removed (this is probably why they do not  
build) out of there and of SConstruct.

In fact, I think this is a very satisfactory situation, envisaged by  
plugin system. Third-party developers maintain and distribute their  
own plugins and we don't have to go round making sure they are kept  
working, up-to-date and having to deliver dependencies in our  
installers. I'm very happy about this.

Saying this, there is a problem with lorismorph (lorisplay and  
lorisread are OK), which is being looked at by Kelly.

Victor

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

Yes, I agree this is the ideal solution with code, but it does pose
issues with documentation. Should these opcodes still be included in
the manual since they are not being distributed with "core" Csound?
But if they are not in the manual, then using them becomes harder
(front-ends will have trouble finding their documentation, and
probably authors won't keep the docs up to date), and less people will
know they exist. Any ideas on how to handle this fragmentation?

I think this is how pd and supercollider typically work, pd objects
usually bundle the documentation patch with the object binaries, and
the user must place it in the appropriate place. Supercollider users
must copy the plugin and docs to a certain directory where they will
be found. But how could we ensure that documentation travels with the
plugin opcodes?

Cheers,
Andrés

On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
 wrote:
> I have looked into the Loris situation and things are much clearer
> now. Kelly Fitz has been very helpful promptly replying to my e-mails.
>
> What happens is that the Loris library now has built-in support for
> Csound as a plugin. So now we do not build the opcodes separately and
> then link to libloris. Kelly has included the code for the opcodes
> inside it so nothing else is needed. In other words: if you build
> Loris with the csound option (enabled by making configure find the
> csound headers), it will include the opcodes.To use them you just have
> to point --opcode-lib to your installed libloris.*
>
> This means probably means that the opcodes in Csound CVS are probably
> out-of-date and should be removed (this is probably why they do not
> build) out of there and of SConstruct.
>
> In fact, I think this is a very satisfactory situation, envisaged by
> plugin system. Third-party developers maintain and distribute their
> own plugins and we don't have to go round making sure they are kept
> working, up-to-date and having to deliver dependencies in our
> installers. I'm very happy about this.
>
> Saying this, there is a problem with lorismorph (lorisplay and
> lorisread are OK), which is being looked at by Kelly.
>
> Victor
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/list

Maybe we could have a special section in the manual for add-ons. We  
can request documentation from third party developers when we find a  
new plugin library we have not documented.

I agree that the on-line documentation in SC3 and PD is a very  
interesting feature. But in the case of PD, at least, it's a  bit  
patchy and nowhere as good as in Csound with its traditional big- 
manual approach.

Victor
On 28 Jul 2010, at 13:13, Andres Cabrera wrote:

> Hi,
>
> Yes, I agree this is the ideal solution with code, but it does pose
> issues with documentation. Should these opcodes still be included in
> the manual since they are not being distributed with "core" Csound?
> But if they are not in the manual, then using them becomes harder
> (front-ends will have trouble finding their documentation, and
> probably authors won't keep the docs up to date), and less people will
> know they exist. Any ideas on how to handle this fragmentation?
>
> I think this is how pd and supercollider typically work, pd objects
> usually bundle the documentation patch with the object binaries, and
> the user must place it in the appropriate place. Supercollider users
> must copy the plugin and docs to a certain directory where they will
> be found. But how could we ensure that documentation travels with the
> plugin opcodes?
>
> Cheers,
> Andrés
>
> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>  wrote:
>> I have looked into the Loris situation and things are much clearer
>> now. Kelly Fitz has been very helpful promptly replying to my e- 
>> mails.
>>
>> What happens is that the Loris library now has built-in support for
>> Csound as a plugin. So now we do not build the opcodes separately and
>> then link to libloris. Kelly has included the code for the opcodes
>> inside it so nothing else is needed. In other words: if you build
>> Loris with the csound option (enabled by making configure find the
>> csound headers), it will include the opcodes.To use them you just  
>> have
>> to point --opcode-lib to your installed libloris.*
>>
>> This means probably means that the opcodes in Csound CVS are probably
>> out-of-date and should be removed (this is probably why they do not
>> build) out of there and of SConstruct.
>>
>> In fact, I think this is a very satisfactory situation, envisaged by
>> plugin system. Third-party developers maintain and distribute their
>> own plugins and we don't have to go round making sure they are kept
>> working, up-to-date and having to deliver dependencies in our
>> installers. I'm very happy about this.
>>
>> Saying this, there is a problem with lorismorph (lorisplay and
>> lorisread are OK), which is being looked at by Kelly.
>>
>> Victor
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This would be great -- if it actually works. Have you tested it? For
both double samples and float samples?

Regards,
Mike

On Wed, Jul 28, 2010 at 8:13 AM, Andres Cabrera  wrote:
> Hi,
>
> Yes, I agree this is the ideal solution with code, but it does pose
> issues with documentation. Should these opcodes still be included in
> the manual since they are not being distributed with "core" Csound?
> But if they are not in the manual, then using them becomes harder
> (front-ends will have trouble finding their documentation, and
> probably authors won't keep the docs up to date), and less people will
> know they exist. Any ideas on how to handle this fragmentation?
>
> I think this is how pd and supercollider typically work, pd objects
> usually bundle the documentation patch with the object binaries, and
> the user must place it in the appropriate place. Supercollider users
> must copy the plugin and docs to a certain directory where they will
> be found. But how could we ensure that documentation travels with the
> plugin opcodes?
>
> Cheers,
> Andrés
>
> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>  wrote:
>> I have looked into the Loris situation and things are much clearer
>> now. Kelly Fitz has been very helpful promptly replying to my e-mails.
>>
>> What happens is that the Loris library now has built-in support for
>> Csound as a plugin. So now we do not build the opcodes separately and
>> then link to libloris. Kelly has included the code for the opcodes
>> inside it so nothing else is needed. In other words: if you build
>> Loris with the csound option (enabled by making configure find the
>> csound headers), it will include the opcodes.To use them you just have
>> to point --opcode-lib to your installed libloris.*
>>
>> This means probably means that the opcodes in Csound CVS are probably
>> out-of-date and should be removed (this is probably why they do not
>> build) out of there and of SConstruct.
>>
>> In fact, I think this is a very satisfactory situation, envisaged by
>> plugin system. Third-party developers maintain and distribute their
>> own plugins and we don't have to go round making sure they are kept
>> working, up-to-date and having to deliver dependencies in our
>> installers. I'm very happy about this.
>>
>> Saying this, there is a problem with lorismorph (lorisplay and
>> lorisread are OK), which is being looked at by Kelly.
>>
>> Victor
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://ad.doubleclick.net/clk;226879339;13503038;l?
> http://clk.atdmt.com/CRS/go/247765532/direct/01/
> _______________________________________________
> 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

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It works for floats (except for lorismorph which is broken), as it is  
what Loris is designed to be built for with the standard configure  
options. I think just adding -DUSE_DOUBLE to configure might do the  
trick to build it for doubles. In any case, I assume it will work.

Victor


On 28 Jul 2010, at 14:31, Michael Gogins wrote:

> This would be great -- if it actually works. Have you tested it? For
> both double samples and float samples?
>
> Regards,
> Mike
>
> On Wed, Jul 28, 2010 at 8:13 AM, Andres Cabrera  
>  wrote:
>> Hi,
>>
>> Yes, I agree this is the ideal solution with code, but it does pose
>> issues with documentation. Should these opcodes still be included in
>> the manual since they are not being distributed with "core" Csound?
>> But if they are not in the manual, then using them becomes harder
>> (front-ends will have trouble finding their documentation, and
>> probably authors won't keep the docs up to date), and less people  
>> will
>> know they exist. Any ideas on how to handle this fragmentation?
>>
>> I think this is how pd and supercollider typically work, pd objects
>> usually bundle the documentation patch with the object binaries, and
>> the user must place it in the appropriate place. Supercollider users
>> must copy the plugin and docs to a certain directory where they will
>> be found. But how could we ensure that documentation travels with the
>> plugin opcodes?
>>
>> Cheers,
>> Andrés
>>
>> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>>  wrote:
>>> I have looked into the Loris situation and things are much clearer
>>> now. Kelly Fitz has been very helpful promptly replying to my e- 
>>> mails.
>>>
>>> What happens is that the Loris library now has built-in support for
>>> Csound as a plugin. So now we do not build the opcodes separately  
>>> and
>>> then link to libloris. Kelly has included the code for the opcodes
>>> inside it so nothing else is needed. In other words: if you build
>>> Loris with the csound option (enabled by making configure find the
>>> csound headers), it will include the opcodes.To use them you just  
>>> have
>>> to point --opcode-lib to your installed libloris.*
>>>
>>> This means probably means that the opcodes in Csound CVS are  
>>> probably
>>> out-of-date and should be removed (this is probably why they do not
>>> build) out of there and of SConstruct.
>>>
>>> In fact, I think this is a very satisfactory situation, envisaged by
>>> plugin system. Third-party developers maintain and distribute their
>>> own plugins and we don't have to go round making sure they are kept
>>> working, up-to-date and having to deliver dependencies in our
>>> installers. I'm very happy about this.
>>>
>>> Saying this, there is a problem with lorismorph (lorisplay and
>>> lorisread are OK), which is being looked at by Kelly.
>>>
>>> Victor
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a  
>>> share
>>> of $1 Million in cash or HP Products. Visit us here for more  
>>> details:
>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> _______________________________________________
>> 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
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm thinking it's probably better to have the manual include all
opcodes even if they are not part of "core" Csound (although all
opcode writers should be encouraged to write their own manual entries
for inclusion in the main manual). I was thinking of adding a section
at the end of all entries which details the name of the plugin library
and whether it's "core" or "external", and if it is extension, to give
the project address. Now thinking, I think it would also be good to
add platform compatibility information to that section. Any other
things that should go there?

I also think that even if they are "external" opcodes, if they do
spectral processing, they should be in the spectral processing
category, so people can find them. This would act also in a way as
advertisement to the plugin libraries.

Cheers,
Andrés

On Wed, Jul 28, 2010 at 2:25 PM, Victor Lazzarini
 wrote:
> Maybe we could have a special section in the manual for add-ons. We
> can request documentation from third party developers when we find a
> new plugin library we have not documented.
>
> I agree that the on-line documentation in SC3 and PD is a very
> interesting feature. But in the case of PD, at least, it's a  bit
> patchy and nowhere as good as in Csound with its traditional big-
> manual approach.
>
> Victor
> On 28 Jul 2010, at 13:13, Andres Cabrera wrote:
>
>> Hi,
>>
>> Yes, I agree this is the ideal solution with code, but it does pose
>> issues with documentation. Should these opcodes still be included in
>> the manual since they are not being distributed with "core" Csound?
>> But if they are not in the manual, then using them becomes harder
>> (front-ends will have trouble finding their documentation, and
>> probably authors won't keep the docs up to date), and less people will
>> know they exist. Any ideas on how to handle this fragmentation?
>>
>> I think this is how pd and supercollider typically work, pd objects
>> usually bundle the documentation patch with the object binaries, and
>> the user must place it in the appropriate place. Supercollider users
>> must copy the plugin and docs to a certain directory where they will
>> be found. But how could we ensure that documentation travels with the
>> plugin opcodes?
>>
>> Cheers,
>> Andrés
>>
>> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>>  wrote:
>>> I have looked into the Loris situation and things are much clearer
>>> now. Kelly Fitz has been very helpful promptly replying to my e-
>>> mails.
>>>
>>> What happens is that the Loris library now has built-in support for
>>> Csound as a plugin. So now we do not build the opcodes separately and
>>> then link to libloris. Kelly has included the code for the opcodes
>>> inside it so nothing else is needed. In other words: if you build
>>> Loris with the csound option (enabled by making configure find the
>>> csound headers), it will include the opcodes.To use them you just
>>> have
>>> to point --opcode-lib to your installed libloris.*
>>>
>>> This means probably means that the opcodes in Csound CVS are probably
>>> out-of-date and should be removed (this is probably why they do not
>>> build) out of there and of SConstruct.
>>>
>>> In fact, I think this is a very satisfactory situation, envisaged by
>>> plugin system. Third-party developers maintain and distribute their
>>> own plugins and we don't have to go round making sure they are kept
>>> working, up-to-date and having to deliver dependencies in our
>>> installers. I'm very happy about this.
>>>
>>> Saying this, there is a problem with lorismorph (lorisplay and
>>> lorisread are OK), which is being looked at by Kelly.
>>>
>>> Victor
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourcefor

Something else that could go there is licence of the plugin library.

Cheers,
Andrés

On Sat, Jul 31, 2010 at 9:01 AM, Andres Cabrera  wrote:
> I'm thinking it's probably better to have the manual include all
> opcodes even if they are not part of "core" Csound (although all
> opcode writers should be encouraged to write their own manual entries
> for inclusion in the main manual). I was thinking of adding a section
> at the end of all entries which details the name of the plugin library
> and whether it's "core" or "external", and if it is extension, to give
> the project address. Now thinking, I think it would also be good to
> add platform compatibility information to that section. Any other
> things that should go there?
>
> I also think that even if they are "external" opcodes, if they do
> spectral processing, they should be in the spectral processing
> category, so people can find them. This would act also in a way as
> advertisement to the plugin libraries.
>
> Cheers,
> Andrés
>
> On Wed, Jul 28, 2010 at 2:25 PM, Victor Lazzarini
>  wrote:
>> Maybe we could have a special section in the manual for add-ons. We
>> can request documentation from third party developers when we find a
>> new plugin library we have not documented.
>>
>> I agree that the on-line documentation in SC3 and PD is a very
>> interesting feature. But in the case of PD, at least, it's a  bit
>> patchy and nowhere as good as in Csound with its traditional big-
>> manual approach.
>>
>> Victor
>> On 28 Jul 2010, at 13:13, Andres Cabrera wrote:
>>
>>> Hi,
>>>
>>> Yes, I agree this is the ideal solution with code, but it does pose
>>> issues with documentation. Should these opcodes still be included in
>>> the manual since they are not being distributed with "core" Csound?
>>> But if they are not in the manual, then using them becomes harder
>>> (front-ends will have trouble finding their documentation, and
>>> probably authors won't keep the docs up to date), and less people will
>>> know they exist. Any ideas on how to handle this fragmentation?
>>>
>>> I think this is how pd and supercollider typically work, pd objects
>>> usually bundle the documentation patch with the object binaries, and
>>> the user must place it in the appropriate place. Supercollider users
>>> must copy the plugin and docs to a certain directory where they will
>>> be found. But how could we ensure that documentation travels with the
>>> plugin opcodes?
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>>>  wrote:
>>>> I have looked into the Loris situation and things are much clearer
>>>> now. Kelly Fitz has been very helpful promptly replying to my e-
>>>> mails.
>>>>
>>>> What happens is that the Loris library now has built-in support for
>>>> Csound as a plugin. So now we do not build the opcodes separately and
>>>> then link to libloris. Kelly has included the code for the opcodes
>>>> inside it so nothing else is needed. In other words: if you build
>>>> Loris with the csound option (enabled by making configure find the
>>>> csound headers), it will include the opcodes.To use them you just
>>>> have
>>>> to point --opcode-lib to your installed libloris.*
>>>>
>>>> This means probably means that the opcodes in Csound CVS are probably
>>>> out-of-date and should be removed (this is probably why they do not
>>>> build) out of there and of SConstruct.
>>>>
>>>> In fact, I think this is a very satisfactory situation, envisaged by
>>>> plugin system. Third-party developers maintain and distribute their
>>>> own plugins and we don't have to go round making sure they are kept
>>>> working, up-to-date and having to deliver dependencies in our
>>>> installers. I'm very happy about this.
>>>>
>>>> Saying this, there is a problem with lorismorph (lorisplay and
>>>> lorisread are OK), which is being looked at by Kelly.
>>>>
>>>> Victor
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The Palm PDK Hot Apps Program offers developers who use the
>>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
>
> Andrés
>



-- 


Andrés

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/li

yes, that seems like a good idea. I guess there are 3 categories:

1. built-in.
2. plugin, csound-maintained.
3. plugin, external project.


Victor


On 31 Jul 2010, at 09:01, Andres Cabrera wrote:

> I'm thinking it's probably better to have the manual include all
> opcodes even if they are not part of "core" Csound (although all
> opcode writers should be encouraged to write their own manual entries
> for inclusion in the main manual). I was thinking of adding a section
> at the end of all entries which details the name of the plugin library
> and whether it's "core" or "external", and if it is extension, to give
> the project address. Now thinking, I think it would also be good to
> add platform compatibility information to that section. Any other
> things that should go there?
>
> I also think that even if they are "external" opcodes, if they do
> spectral processing, they should be in the spectral processing
> category, so people can find them. This would act also in a way as
> advertisement to the plugin libraries.
>
> Cheers,
> Andrés
>
> On Wed, Jul 28, 2010 at 2:25 PM, Victor Lazzarini
>  wrote:
>> Maybe we could have a special section in the manual for add-ons. We
>> can request documentation from third party developers when we find a
>> new plugin library we have not documented.
>>
>> I agree that the on-line documentation in SC3 and PD is a very
>> interesting feature. But in the case of PD, at least, it's a  bit
>> patchy and nowhere as good as in Csound with its traditional big-
>> manual approach.
>>
>> Victor
>> On 28 Jul 2010, at 13:13, Andres Cabrera wrote:
>>
>>> Hi,
>>>
>>> Yes, I agree this is the ideal solution with code, but it does pose
>>> issues with documentation. Should these opcodes still be included in
>>> the manual since they are not being distributed with "core" Csound?
>>> But if they are not in the manual, then using them becomes harder
>>> (front-ends will have trouble finding their documentation, and
>>> probably authors won't keep the docs up to date), and less people  
>>> will
>>> know they exist. Any ideas on how to handle this fragmentation?
>>>
>>> I think this is how pd and supercollider typically work, pd objects
>>> usually bundle the documentation patch with the object binaries, and
>>> the user must place it in the appropriate place. Supercollider users
>>> must copy the plugin and docs to a certain directory where they will
>>> be found. But how could we ensure that documentation travels with  
>>> the
>>> plugin opcodes?
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Wed, Jul 28, 2010 at 1:12 PM, Victor Lazzarini
>>>  wrote:
>>>> I have looked into the Loris situation and things are much clearer
>>>> now. Kelly Fitz has been very helpful promptly replying to my e-
>>>> mails.
>>>>
>>>> What happens is that the Loris library now has built-in support for
>>>> Csound as a plugin. So now we do not build the opcodes separately  
>>>> and
>>>> then link to libloris. Kelly has included the code for the opcodes
>>>> inside it so nothing else is needed. In other words: if you build
>>>> Loris with the csound option (enabled by making configure find the
>>>> csound headers), it will include the opcodes.To use them you just
>>>> have
>>>> to point --opcode-lib to your installed libloris.*
>>>>
>>>> This means probably means that the opcodes in Csound CVS are  
>>>> probably
>>>> out-of-date and should be removed (this is probably why they do not
>>>> build) out of there and of SConstruct.
>>>>
>>>> In fact, I think this is a very satisfactory situation, envisaged  
>>>> by
>>>> plugin system. Third-party developers maintain and distribute their
>>>> own plugins and we don't have to go round making sure they are kept
>>>> working, up-to-date and having to deliver dependencies in our
>>>> installers. I'm very happy about this.
>>>>
>>>> Saying this, there is a problem with lorismorph (lorisplay and
>>>> lorisread are OK), which is being looked at by Kelly.
>>>>
>>>> Victor
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The Palm PDK Hot Apps Program offers developers who use the
>>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a  
>>>> share
>>>> of $1 Million in cash or HP Products. Visit us here for more  
>>>> details:
>>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> Andrés
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a  
>>> share
>>> of $1 Million in cash or HP Products. Visit us here for more  
>>> details:
>>> http://ad.doubleclick.net/clk;226879339;13503038;l?
>>> http://clk.atdmt.com/CRS/go/247765532/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> yes, that seems like a good idea. I guess there are 3 categories:
>
> 1. built-in.
> 2. plugin, csound-maintained.
> 3. plugin, external project.
>
>
> Victor
>

A good idea, but perhapos it is time to reconsider what opcodes should be
in the core code

==John ff


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,

is it possible to include the 27 STK opcodes in the manual as well? These
opcodes are also optional and at the moment not at all documented in the
manual.
I would like to upload examples to the examples folder of the manual if
everyone agrees.
Maybe Michael Gogins could create a page for the manual?

menno
-- 
View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2265309.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Menno,

I think it would be good if they are documented. Would they make the
older physical modeling objects based on STK obsolete?

Cheers,
Andres

On Thu, Aug 5, 2010 at 2:11 PM, menno  wrote:
>
> Hi,
>
> is it possible to include the 27 STK opcodes in the manual as well? These
> opcodes are also optional and at the moment not at all documented in the
> manual.
> I would like to upload examples to the examples folder of the manual if
> everyone agrees.
> Maybe Michael Gogins could create a page for the manual?
>
> menno
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2265309.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sour

No, jpff did a good job, they sound different but both are useful.

MKG from cell phone

On Aug 6, 2010 3:40 AM, "Andres Cabrera" <mantaraya36@gmail.com> wrote:

Hi Menno,

I think it would be good if they are documented. Would they make the
older physical modeling objects based on STK obsolete?

Cheers,
Andres

On Thu, Aug 5, 2010 at 2:11 PM, menno <nabob_cd@yahoo.com> wrote:
>
> Hi,
>
> is it possible to inc...

--


Andrés

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev

_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourcef...

okay, great.
Michael, will you make a page for the manual or do you prefer that i will
make an attempt to do so?
Anyway, i will upload the 27 examples for the manual.

Menno
-- 
View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2266615.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am overloaded with work right now. I would prefer it if you do the
manual page. But I will help you. All the opcodes work the same way,
the only difference is the krate control parameters that can be passed
in the 4 pfields. Currently these are documented only in the STK
source code. I can write an outline of the manual page to be varied
with this information if you look up the parameters from the source
code.

Regards,
Mike

On Fri, Aug 6, 2010 at 9:26 AM, menno  wrote:
>
> okay, great.
> Michael, will you make a page for the manual or do you prefer that i will
> make an attempt to do so?
> Anyway, i will upload the 27 examples for the manual.
>
> Menno
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2266615.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> 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

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael, this example gives an error:



-odac  



; Initialize the global variables.
sr = 44100
kr = 4410
ksmps = 10
nchnls = 2

; Instrument #1.
instr 1 ;STK Flute
kjet	line	1, p3, 100
;asignal STKName ifreq igain ,cont1,val1,cont2,val2,cont3, val3,cont4, val4
asignal STKFlute 400, 1, 2, kjet
asignal = asignal*30000		;amplify
outs asignal, asignal
endin




i 1 0 5 
e




The error is:
error:  input arg 'kjet' of type k not allowed when expecting j, line 21:
asignal STKFlute 400, 1, 2, kjet
1 syntax errors in orchestra.  compilation invalid

replacing kjet by a constant value works fine.

regards,
Menno
-- 
View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2267633.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

This is the same problem we discussed before. I am fixing it now.

Regards,
Mike

On Sat, Aug 7, 2010 at 2:10 PM, menno  wrote:
>
> Michael, this example gives an error:
>
> 
> 
> -odac
> 
> 
>
> ; Initialize the global variables.
> sr = 44100
> kr = 4410
> ksmps = 10
> nchnls = 2
>
> ; Instrument #1.
> instr 1 ;STK Flute
> kjet    line    1, p3, 100
> ;asignal STKName ifreq igain ,cont1,val1,cont2,val2,cont3, val3,cont4, val4
> asignal STKFlute 400, 1, 2, kjet
> asignal = asignal*30000         ;amplify
> outs asignal, asignal
> endin
>
> 
> 
>
> i 1 0 5
> e
> 
> 
>
>
> The error is:
> error:  input arg 'kjet' of type k not allowed when expecting j, line 21:
> asignal STKFlute 400, 1, 2, kjet
> 1 syntax errors in orchestra.  compilation invalid
>
> replacing kjet by a constant value works fine.
>
> regards,
> Menno
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2267633.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> 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

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The STK opcode controllers and values have been changed to k-rate
defaulting to -1, which is what they were supposed to be in the first
place. This is now in CVS.

Regards,
Mike

On Sat, Aug 7, 2010 at 2:27 PM, Michael Gogins  wrote:
> This is the same problem we discussed before. I am fixing it now.
>
> Regards,
> Mike
>
> On Sat, Aug 7, 2010 at 2:10 PM, menno  wrote:
>>
>> Michael, this example gives an error:
>>
>> 
>> 
>> -odac
>> 
>> 
>>
>> ; Initialize the global variables.
>> sr = 44100
>> kr = 4410
>> ksmps = 10
>> nchnls = 2
>>
>> ; Instrument #1.
>> instr 1 ;STK Flute
>> kjet    line    1, p3, 100
>> ;asignal STKName ifreq igain ,cont1,val1,cont2,val2,cont3, val3,cont4, val4
>> asignal STKFlute 400, 1, 2, kjet
>> asignal = asignal*30000         ;amplify
>> outs asignal, asignal
>> endin
>>
>> 
>> 
>>
>> i 1 0 5
>> e
>> 
>> 
>>
>>
>> The error is:
>> error:  input arg 'kjet' of type k not allowed when expecting j, line 21:
>> asignal STKFlute 400, 1, 2, kjet
>> 1 syntax errors in orchestra.  compilation invalid
>>
>> replacing kjet by a constant value works fine.
>>
>> regards,
>> Menno
>> --
>> View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2267633.html
>> Sent from the Csound - Dev mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> 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
>



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

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Michael,

perhaps the time has come to make manual entries for the STK opcodes? I am
in the process of creating examples for the manual for every one of them. If
not, please let me know and we can synchronize another time, np.
But in case you have the time, then:

- If you can, will you write the outline for the manual page? (i'll fill in
the rest and let you know)
- atm there are 4 k-rate values for 4 controllers possible. Can you expand
this to 7? 
There are a few STKopcodes that have that many parameters
- there is another STK opcode,
https://ccrma.stanford.edu/software/stk/classstk_1_1Mesh2D.html , that might
be interesting to make available for Csound. Is it interesting enough and
easy to implement ?

what do you think about all this?

regards,
Menno
-- 
View this message in context: http://csound.1045644.n5.nabble.com/Loris-update-tp2257071p2802100.html
Sent from the Csound - Dev mailing list archive at Nabble.com.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net