Thank you Victor, quick response and all. Figure one of 'brain crowd'
guys would know.

Thanks mate, 
cheers mate,
-Partev


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



--- Victor.Lazzarini@nuim.ie wrote:

From: Victor Lazzarini 
To: csound@lists.bath.ac.uk
Subject: [Csnd] Re:  Re: True Plug and Play  Instruments with Templates
Date: Sat, 12 Sep 2009 23:42:54 +0100

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"



_____________________________________________________________
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"