Michael,

Forgive my ignornce and momentary brain latch-up, but,
what is UDO? And what is OSC (i assume it isn't osc as 
in oscillator)?

-Partev


=======================================================================================



--- michael.gogins@gmail.com wrote:

From: Michael Gogins 
To: csound@lists.bath.ac.uk
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: Re: True Plug and Play  Instruments with Templates
Date: Sat, 12 Sep 2009 14:41:23 -0400

Here is a more developed elaboration of my ideas, in the form of a demo orc.

Regards,
Mike

; Blocks must be declared without connections.
; Connections must declared outside of blocks.
; This is the critical feature that enables blocks to be used,
; without modification, outside of orchestras in which they were defined.

; Dynamic blocks are instrs, but the inlets and outlets are declared
in the block header.
; A new instance of the block is created for each new score event
directed at the block.
; Pfields beyond 3 may also be declared, with optional defaults, and
do not need to be in order or consecutive.
; Inlets and oulets may also be declared with default values.

dynamic "toot" pfields 5, 4, 12=0.0 outlets "left", aleft, "right", aright

; To simplify inter-operability, function tables get a new opcode, identical
; to ftgen, except that no new ftable is created if there is a request
for another
; one of the same signature. In this case, the first instance of "toot" creates
; an instance of an ftable, and all subsequent instances of "toot" re-use tha
; instance of the ftable.

itable ftgenonce 0, 0, 16384, 9, 1, 1, 2, 0.5, 3, 0.25
iamp = ampdb(p4)
ihz = cpsmidinn(p5)
ipan = p12 ; Defaults to 0.0 even if not in score.
kenv madsr 0.05, 0.25, 0.3334, 0.5
asignal poscil3 kenv, ihz, itable

; As left and aright are declared as outlets, out they go.

aleft, aright pan2 asignal, ipan
enddyn

; Static blocks are like UDOs or instrs, but they are always on and do not need
; score events for activation (although they may receive pfields).

static "reverb" pfields 5, 7, 8, 9 inlets "left", ainleft, "right",
ainright, "time", ktime=0.8 outlets "left", aoutleft, "right",
aoutright
aoutleft, aoutright reverbsc ainleft, ainright, ktime, 15000
endstatic

; Send the output of all instances of "toot" to the "reverb" block.

connect "toot" outlets "left", "right" to "reverb" inlets "left", "right"

; Static blocks "soundfileout" and "audiout" are defined in "masterout.csd".
; Note that connect statements in #included files are ignored.

#include "masterout.csd"

; Send the output of "reverb" to both audio output and soundfile
output, defined in an external file.

connect "reverb" outlets "left", "right" to "soundfileout" inlets
"left", "right"
connect "reverb" outlets "left", "right" to "audiout" inlets "left", "right"

On 9/12/09, Oeyvind Brandtsegg  wrote:
> Yes, this could be something very nice.
> I think both Steven and Michael have ideas that makes a lot of sense
> here. I haven't really thought long and hard about this, but I'm glad
> the discussion and thinking of the subject have been revitalized. I
> think we're on to something.
> Oeyvind
>
>
> 2009/9/12 Michael Gogins :
>> I like the motive here, of making instruments more inter-operable.
>>
>> This would be much easier if Csound were a different langauge, or had
>> an alternative different language, that was more like a GUI patching
>> language with sub-patches or abstractions.
>>
>> The math underlying both implementations of the music-N paradigm needs
>> to be clarified. I understand that the GUI patchers are synchronous
>> data flow languages. This is a clearly formalized idea. I don't
>> understand how to formalize my understanding of Csound's language as
>> well.
>>
>> This was one of my motives in introducing the inlet/outlet opcodes,
>> but there is still a problem in that the orchestra writer has to pay
>> too much attention to the order in which instruments are defined, and
>> so far it only would be easy to use with numbered instruments, and not
>> with named instruments and user-defined opcodes.
>>
>> The GUI patchers also require the user to order the unit generators
>> explicitly. But mathematically, it is possible for the language to
>> order all nodes in the graph by traversing all the connections. Doing
>> this in Csound would require changes in the Csound orchestra language
>> and compiler itself, but it would greatly simplify what you guys are
>> trying to achieve. In the other words, the opcode and instr
>> declarations would acquire inlet and outlet parts (optional, of
>> course, for backwards compatibility). Then the Csound orchestra
>> compiler would keep track of all inlets and outlets and use these to
>> traverse the graph and build the right execution order; renumber the
>> instrument numbers, if you will.
>>
>> If this were done then orchestra writers could #include somebody
>> else's orchestra and simply write connections from their outlets to
>> its inlets, and from its outlets to their inlets. I think this is what
>> you guys really want to end up with.
>>
>> To really make this easy, instead of #include, something like an
>> abstraction or subpatch keyword, let's call it suborc, would be
>> introduced, and for this to work, any orchestra would have to be able
>> to have orcinlets and orcoutlets.
>>
>> Function tables would be a problem. I have never liked the way Csound
>> handles function tables, I believe they should normally be defined
>> within the instrument that uses them, but still be shared (this can be
>> done if the arguments to the table are the same).
>>
>> I will try to refine my ideas about actually adding to the Csound
>> orchestra syntax to make this kind of inter-operation more
>> transparent.
>>
>> Regards,
>> Mike
>>
>>
>>
>> On 9/11/09, Jacob Joaquin  wrote:
>>>
>>> I agree with much with what you are saying.
>>>
>>>
>>> Stéphane Rollandin wrote:
>>>>
>>>> Because it could easily become another hack. You may very well end up
>>>> with a specification that fits your purposes, but that will leave
>>>> something to be desired to another person. This person will come up with
>>>> its own specification, very much like what you are doing now, saying
>>>> something like "oh, macros and includes and named instruments and UDOs
>>>> and templates are good, but not enough, here is my solution", and there
>>>> comes another hack.
>>>>
>>>
>>>
>>> You are dead on.  That's why it's important that something like this
>>> shouldn't be implemented over night.  It should take long time - a year
>>> or
>>> longer.  If this were to become part of the core, it would need time to
>>> mature, and would greatly depend on the input from Csounders.
>>>
>>>
>>>
>>> Stéphane Rollandin wrote:
>>>>
>>>> This is because what we are doing here, incrementaly and awkwardly, is
>>>> actually defining a new langage, on top of csound syntax. I personally
>>>> prefer to leave Csound as it is (modulo its continous improvements, of
>>>> course, of which templates may be a part after all), and directly use
>>>> some other high-level language to produce scores and orchestras.
>>>>
>>>
>>>
>>> I also think it is important that, if implemented, it must look and feel
>>> like Csound, blend in.  I think CSD markup tags are a great example of
>>> something that was added to Csound, but failed to incorporate the
>>> existing
>>> aesthetics.
>>>
>>>
>>>
>>> Stéphane Rollandin wrote:
>>>>
>>>> I have been designing such systems for several years know, and I feel
>>>> that Csound low-level, assembly like syntax is not a problem. Higher
>>>> abstractions and modular components can be scripted in Lisp, Python,
>>>> etc.
>>>>
>>>
>>>
>>> The biggest issue I see to relying on other languages to implement is
>>> that
>>> severely reduces the amount of users who will adopt it.  Since one of the
>>> goals is to create a system for Csounder's to share and remix their work,
>>> that could easily be a deal breaker.  However, if in the future Python is
>>> more tightly integrated with Csound in the future, then perhaps a script
>>> would work.
>>>
>>> Best,
>>> Jake
>>> --
>>> View this message in context:
>>> http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25408734.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


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


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



_____________________________________________________________
Netscape.  Just the Net You Need.
Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

User Defined Opcode and Open Sound Control
On 12 Sep 2009, at 23:32, Partev Barr Sarkissian wrote:

> Michael,
>
> Forgive my ignornce and momentary brain latch-up, but,
> what is UDO? And what is OSC (i assume it isn't osc as
> in oscillator)?
>
> -Partev
>
>
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
> --- michael.gogins@gmail.com wrote:
>
> From: Michael Gogins 
> To: csound@lists.bath.ac.uk
> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: Re: True Plug and  
> Play  Instruments with Templates
> Date: Sat, 12 Sep 2009 14:41:23 -0400
>
> Here is a more developed elaboration of my ideas, in the form of a  
> demo orc.
>
> Regards,
> Mike
>
> ; Blocks must be declared without connections.
> ; Connections must declared outside of blocks.
> ; This is the critical feature that enables blocks to be used,
> ; without modification, outside of orchestras in which they were  
> defined.
>
> ; Dynamic blocks are instrs, but the inlets and outlets are declared
> in the block header.
> ; A new instance of the block is created for each new score event
> directed at the block.
> ; Pfields beyond 3 may also be declared, with optional defaults, and
> do not need to be in order or consecutive.
> ; Inlets and oulets may also be declared with default values.
>
> dynamic "toot" pfields 5, 4, 12=0.0 outlets "left", aleft, "right",  
> aright
>
> ; To simplify inter-operability, function tables get a new opcode,  
> identical
> ; to ftgen, except that no new ftable is created if there is a request
> for another
> ; one of the same signature. In this case, the first instance of  
> "toot" creates
> ; an instance of an ftable, and all subsequent instances of "toot"  
> re-use tha
> ; instance of the ftable.
>
> itable ftgenonce 0, 0, 16384, 9, 1, 1, 2, 0.5, 3, 0.25
> iamp = ampdb(p4)
> ihz = cpsmidinn(p5)
> ipan = p12 ; Defaults to 0.0 even if not in score.
> kenv madsr 0.05, 0.25, 0.3334, 0.5
> asignal poscil3 kenv, ihz, itable
>
> ; As left and aright are declared as outlets, out they go.
>
> aleft, aright pan2 asignal, ipan
> enddyn
>
> ; Static blocks are like UDOs or instrs, but they are always on and  
> do not need
> ; score events for activation (although they may receive pfields).
>
> static "reverb" pfields 5, 7, 8, 9 inlets "left", ainleft, "right",
> ainright, "time", ktime=0.8 outlets "left", aoutleft, "right",
> aoutright
> aoutleft, aoutright reverbsc ainleft, ainright, ktime, 15000
> endstatic
>
> ; Send the output of all instances of "toot" to the "reverb" block.
>
> connect "toot" outlets "left", "right" to "reverb" inlets "left",  
> "right"
>
> ; Static blocks "soundfileout" and "audiout" are defined in  
> "masterout.csd".
> ; Note that connect statements in #included files are ignored.
>
> #include "masterout.csd"
>
> ; Send the output of "reverb" to both audio output and soundfile
> output, defined in an external file.
>
> connect "reverb" outlets "left", "right" to "soundfileout" inlets
> "left", "right"
> connect "reverb" outlets "left", "right" to "audiout" inlets "left",  
> "right"
>
> On 9/12/09, Oeyvind Brandtsegg  wrote:
>> Yes, this could be something very nice.
>> I think both Steven and Michael have ideas that makes a lot of sense
>> here. I haven't really thought long and hard about this, but I'm glad
>> the discussion and thinking of the subject have been revitalized. I
>> think we're on to something.
>> Oeyvind
>>
>>
>> 2009/9/12 Michael Gogins :
>>> I like the motive here, of making instruments more inter-operable.
>>>
>>> This would be much easier if Csound were a different langauge, or  
>>> had
>>> an alternative different language, that was more like a GUI patching
>>> language with sub-patches or abstractions.
>>>
>>> The math underlying both implementations of the music-N paradigm  
>>> needs
>>> to be clarified. I understand that the GUI patchers are synchronous
>>> data flow languages. This is a clearly formalized idea. I don't
>>> understand how to formalize my understanding of Csound's language as
>>> well.
>>>
>>> This was one of my motives in introducing the inlet/outlet opcodes,
>>> but there is still a problem in that the orchestra writer has to pay
>>> too much attention to the order in which instruments are defined,  
>>> and
>>> so far it only would be easy to use with numbered instruments, and  
>>> not
>>> with named instruments and user-defined opcodes.
>>>
>>> The GUI patchers also require the user to order the unit generators
>>> explicitly. But mathematically, it is possible for the language to
>>> order all nodes in the graph by traversing all the connections.  
>>> Doing
>>> this in Csound would require changes in the Csound orchestra  
>>> language
>>> and compiler itself, but it would greatly simplify what you guys are
>>> trying to achieve. In the other words, the opcode and instr
>>> declarations would acquire inlet and outlet parts (optional, of
>>> course, for backwards compatibility). Then the Csound orchestra
>>> compiler would keep track of all inlets and outlets and use these to
>>> traverse the graph and build the right execution order; renumber the
>>> instrument numbers, if you will.
>>>
>>> If this were done then orchestra writers could #include somebody
>>> else's orchestra and simply write connections from their outlets to
>>> its inlets, and from its outlets to their inlets. I think this is  
>>> what
>>> you guys really want to end up with.
>>>
>>> To really make this easy, instead of #include, something like an
>>> abstraction or subpatch keyword, let's call it suborc, would be
>>> introduced, and for this to work, any orchestra would have to be  
>>> able
>>> to have orcinlets and orcoutlets.
>>>
>>> Function tables would be a problem. I have never liked the way  
>>> Csound
>>> handles function tables, I believe they should normally be defined
>>> within the instrument that uses them, but still be shared (this  
>>> can be
>>> done if the arguments to the table are the same).
>>>
>>> I will try to refine my ideas about actually adding to the Csound
>>> orchestra syntax to make this kind of inter-operation more
>>> transparent.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> On 9/11/09, Jacob Joaquin  wrote:
>>>>
>>>> I agree with much with what you are saying.
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> Because it could easily become another hack. You may very well  
>>>>> end up
>>>>> with a specification that fits your purposes, but that will leave
>>>>> something to be desired to another person. This person will come  
>>>>> up with
>>>>> its own specification, very much like what you are doing now,  
>>>>> saying
>>>>> something like "oh, macros and includes and named instruments  
>>>>> and UDOs
>>>>> and templates are good, but not enough, here is my solution",  
>>>>> and there
>>>>> comes another hack.
>>>>>
>>>>
>>>>
>>>> You are dead on.  That's why it's important that something like  
>>>> this
>>>> shouldn't be implemented over night.  It should take long time -  
>>>> a year
>>>> or
>>>> longer.  If this were to become part of the core, it would need  
>>>> time to
>>>> mature, and would greatly depend on the input from Csounders.
>>>>
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> This is because what we are doing here, incrementaly and  
>>>>> awkwardly, is
>>>>> actually defining a new langage, on top of csound syntax. I  
>>>>> personally
>>>>> prefer to leave Csound as it is (modulo its continous  
>>>>> improvements, of
>>>>> course, of which templates may be a part after all), and  
>>>>> directly use
>>>>> some other high-level language to produce scores and orchestras.
>>>>>
>>>>
>>>>
>>>> I also think it is important that, if implemented, it must look  
>>>> and feel
>>>> like Csound, blend in.  I think CSD markup tags are a great  
>>>> example of
>>>> something that was added to Csound, but failed to incorporate the
>>>> existing
>>>> aesthetics.
>>>>
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> I have been designing such systems for several years know, and I  
>>>>> feel
>>>>> that Csound low-level, assembly like syntax is not a problem.  
>>>>> Higher
>>>>> abstractions and modular components can be scripted in Lisp,  
>>>>> Python,
>>>>> etc.
>>>>>
>>>>
>>>>
>>>> The biggest issue I see to relying on other languages to  
>>>> implement is
>>>> that
>>>> severely reduces the amount of users who will adopt it.  Since  
>>>> one of the
>>>> goals is to create a system for Csounder's to share and remix  
>>>> their work,
>>>> that could easily be a deal breaker.  However, if in the future  
>>>> Python is
>>>> more tightly integrated with Csound in the future, then perhaps a  
>>>> script
>>>> would work.
>>>>
>>>> Best,
>>>> Jake
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25408734.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>
>
>
> _____________________________________________________________
> Netscape.  Just the Net You Need.
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I don't find OSC in the message.

UDO is User-Defined Opcode, they keywords are opcode and endop like
instr and endin.

Regards,
Mike

On 9/12/09, Partev Barr Sarkissian  wrote:
> Michael,
>
> Forgive my ignornce and momentary brain latch-up, but,
> what is UDO? And what is OSC (i assume it isn't osc as
> in oscillator)?
>
> -Partev
>
>
> =======================================================================================
>
>
>
> --- michael.gogins@gmail.com wrote:
>
> From: Michael Gogins 
> To: csound@lists.bath.ac.uk
> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: Re: True Plug and Play
> Instruments with Templates
> Date: Sat, 12 Sep 2009 14:41:23 -0400
>
> Here is a more developed elaboration of my ideas, in the form of a demo
> orc.
>
> Regards,
> Mike
>
> ; Blocks must be declared without connections.
> ; Connections must declared outside of blocks.
> ; This is the critical feature that enables blocks to be used,
> ; without modification, outside of orchestras in which they were defined.
>
> ; Dynamic blocks are instrs, but the inlets and outlets are declared
> in the block header.
> ; A new instance of the block is created for each new score event
> directed at the block.
> ; Pfields beyond 3 may also be declared, with optional defaults, and
> do not need to be in order or consecutive.
> ; Inlets and oulets may also be declared with default values.
>
> dynamic "toot" pfields 5, 4, 12=0.0 outlets "left", aleft, "right", aright
>
> ; To simplify inter-operability, function tables get a new opcode,
> identical
> ; to ftgen, except that no new ftable is created if there is a request
> for another
> ; one of the same signature. In this case, the first instance of "toot"
> creates
> ; an instance of an ftable, and all subsequent instances of "toot" re-use
> tha
> ; instance of the ftable.
>
> itable ftgenonce 0, 0, 16384, 9, 1, 1, 2, 0.5, 3, 0.25
> iamp = ampdb(p4)
> ihz = cpsmidinn(p5)
> ipan = p12 ; Defaults to 0.0 even if not in score.
> kenv madsr 0.05, 0.25, 0.3334, 0.5
> asignal poscil3 kenv, ihz, itable
>
> ; As left and aright are declared as outlets, out they go.
>
> aleft, aright pan2 asignal, ipan
> enddyn
>
> ; Static blocks are like UDOs or instrs, but they are always on and do not
> need
> ; score events for activation (although they may receive pfields).
>
> static "reverb" pfields 5, 7, 8, 9 inlets "left", ainleft, "right",
> ainright, "time", ktime=0.8 outlets "left", aoutleft, "right",
> aoutright
> aoutleft, aoutright reverbsc ainleft, ainright, ktime, 15000
> endstatic
>
> ; Send the output of all instances of "toot" to the "reverb" block.
>
> connect "toot" outlets "left", "right" to "reverb" inlets "left", "right"
>
> ; Static blocks "soundfileout" and "audiout" are defined in
> "masterout.csd".
> ; Note that connect statements in #included files are ignored.
>
> #include "masterout.csd"
>
> ; Send the output of "reverb" to both audio output and soundfile
> output, defined in an external file.
>
> connect "reverb" outlets "left", "right" to "soundfileout" inlets
> "left", "right"
> connect "reverb" outlets "left", "right" to "audiout" inlets "left",
> "right"
>
> On 9/12/09, Oeyvind Brandtsegg  wrote:
>> Yes, this could be something very nice.
>> I think both Steven and Michael have ideas that makes a lot of sense
>> here. I haven't really thought long and hard about this, but I'm glad
>> the discussion and thinking of the subject have been revitalized. I
>> think we're on to something.
>> Oeyvind
>>
>>
>> 2009/9/12 Michael Gogins :
>>> I like the motive here, of making instruments more inter-operable.
>>>
>>> This would be much easier if Csound were a different langauge, or had
>>> an alternative different language, that was more like a GUI patching
>>> language with sub-patches or abstractions.
>>>
>>> The math underlying both implementations of the music-N paradigm needs
>>> to be clarified. I understand that the GUI patchers are synchronous
>>> data flow languages. This is a clearly formalized idea. I don't
>>> understand how to formalize my understanding of Csound's language as
>>> well.
>>>
>>> This was one of my motives in introducing the inlet/outlet opcodes,
>>> but there is still a problem in that the orchestra writer has to pay
>>> too much attention to the order in which instruments are defined, and
>>> so far it only would be easy to use with numbered instruments, and not
>>> with named instruments and user-defined opcodes.
>>>
>>> The GUI patchers also require the user to order the unit generators
>>> explicitly. But mathematically, it is possible for the language to
>>> order all nodes in the graph by traversing all the connections. Doing
>>> this in Csound would require changes in the Csound orchestra language
>>> and compiler itself, but it would greatly simplify what you guys are
>>> trying to achieve. In the other words, the opcode and instr
>>> declarations would acquire inlet and outlet parts (optional, of
>>> course, for backwards compatibility). Then the Csound orchestra
>>> compiler would keep track of all inlets and outlets and use these to
>>> traverse the graph and build the right execution order; renumber the
>>> instrument numbers, if you will.
>>>
>>> If this were done then orchestra writers could #include somebody
>>> else's orchestra and simply write connections from their outlets to
>>> its inlets, and from its outlets to their inlets. I think this is what
>>> you guys really want to end up with.
>>>
>>> To really make this easy, instead of #include, something like an
>>> abstraction or subpatch keyword, let's call it suborc, would be
>>> introduced, and for this to work, any orchestra would have to be able
>>> to have orcinlets and orcoutlets.
>>>
>>> Function tables would be a problem. I have never liked the way Csound
>>> handles function tables, I believe they should normally be defined
>>> within the instrument that uses them, but still be shared (this can be
>>> done if the arguments to the table are the same).
>>>
>>> I will try to refine my ideas about actually adding to the Csound
>>> orchestra syntax to make this kind of inter-operation more
>>> transparent.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>>
>>> On 9/11/09, Jacob Joaquin  wrote:
>>>>
>>>> I agree with much with what you are saying.
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> Because it could easily become another hack. You may very well end up
>>>>> with a specification that fits your purposes, but that will leave
>>>>> something to be desired to another person. This person will come up
>>>>> with
>>>>> its own specification, very much like what you are doing now, saying
>>>>> something like "oh, macros and includes and named instruments and UDOs
>>>>> and templates are good, but not enough, here is my solution", and
>>>>> there
>>>>> comes another hack.
>>>>>
>>>>
>>>>
>>>> You are dead on.  That's why it's important that something like this
>>>> shouldn't be implemented over night.  It should take long time - a year
>>>> or
>>>> longer.  If this were to become part of the core, it would need time to
>>>> mature, and would greatly depend on the input from Csounders.
>>>>
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> This is because what we are doing here, incrementaly and awkwardly, is
>>>>> actually defining a new langage, on top of csound syntax. I personally
>>>>> prefer to leave Csound as it is (modulo its continous improvements, of
>>>>> course, of which templates may be a part after all), and directly use
>>>>> some other high-level language to produce scores and orchestras.
>>>>>
>>>>
>>>>
>>>> I also think it is important that, if implemented, it must look and
>>>> feel
>>>> like Csound, blend in.  I think CSD markup tags are a great example of
>>>> something that was added to Csound, but failed to incorporate the
>>>> existing
>>>> aesthetics.
>>>>
>>>>
>>>>
>>>> Stéphane Rollandin wrote:
>>>>>
>>>>> I have been designing such systems for several years know, and I feel
>>>>> that Csound low-level, assembly like syntax is not a problem. Higher
>>>>> abstractions and modular components can be scripted in Lisp, Python,
>>>>> etc.
>>>>>
>>>>
>>>>
>>>> The biggest issue I see to relying on other languages to implement is
>>>> that
>>>> severely reduces the amount of users who will adopt it.  Since one of
>>>> the
>>>> goals is to create a system for Csounder's to share and remix their
>>>> work,
>>>> that could easily be a deal breaker.  However, if in the future Python
>>>> is
>>>> more tightly integrated with Csound in the future, then perhaps a
>>>> script
>>>> would work.
>>>>
>>>> Best,
>>>> Jake
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25408734.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
> _____________________________________________________________
> Netscape.  Just the Net You Need.
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"


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


Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"