Reusing a Csound instrument in a new score typically involves copying and
pasting the instrument into a new orchestra.  Once pasted, the user, more
often than not, must make modifications to the instrument in order for it to
work in its new environment.  Sometimes it is only a matter of changing the
instrument number.  Other times, f-tables have to be ported and renumbered
as well.  If there are software busses involve, such as zak, then
modifications suddenly become a minor rewrite of the instrument.

No one enjoys this.  Well, statistically speaking, I'm sure there is a
handful of people that do.  Though as a general rule, this is tedious work
that most Csounders would rather do without.

I propose that we develop an instrument templating system for handling,
importing and reusing instruments.

In a nutshell, an instrument template is basically a Csound instrument,
minus an assigned instrument number, plus it can support additional
variables the can be designated when constructed. Here is an example of what
a Csound instrument template might look like:

    template Sinewave440
        a1 oscils 1, 440, 1
        out a1
    end_template

In this very basic example, the code in the body is 100% Csound.  This is
important because templates should look familiar to Csounders.  Templates
would exist in an orchestra, or in an external file.  In order to use this
template, an instrument must be created from it.  The code to do this might
look like this:

    create_instr 1 Sinewave440

Or if the template exists in external file:

    import_template Sinewave440 from "./foo.orc"
    create_instr 1 Sinewave440
    
The instrument as it is only works when nchnls is set to one. Since
portability is a goal, I will modify this template to make it more of a
general purpose template.  Instead of sending a1 to the dac using out, I
will instead send it to an audio buss using the upcoming outleta opcode.

    template Sinewave262 #output
        a1 oscils 1, 262, 1
        outleta a1, #output
    end_template

Here, I introduced template arguments.  The example uses one argument,
#output.  What ever text is supplied as the first parameter will replace
#output in the body of the template, much like a macro.

    create_instr 1 Sinewave262 "audio_out"
    
After the preprocessor, the following Csound code is produced:

    instr 1
        a1 oscils 1, 262, 1
        outleta a1, "audio_out"
    endin

To hear the audio, we still need to create an instrument that receives the
audio and sends it to the dac or audio file.

    template StereoOut #left_input #right_input
        a1 inleta #left_input
        a2 inleta #right_input
        output a1, a2
    end_template

    create_instr 1 Sinewave262 "audio_out"
    create_instr 2 StereoOut "audio_out" "audio_out"
    
After the preprocessor, the previous code would produce the following
orchestra code:

    instr 1
        a1 oscils 1, 262, 1
        outleta a1, "audio_out"
    endin

    instr 2
        a1 inleta "audio_out"
        a2 inleta "audio_out"
        output a1, a2
    endin

The greater implication is that instruments/templates could be used in a
much more modular fashion.  Since numbers and buss names aren't assigned
until an instr is created, Csounders would be able to patch together complex
systems far easier and faster than is currently possible.

Here is a longer example that makes use of this theoretical patching system:

    template MySynth #output #fn
        iamp = p4
        ifreq = p5
        ifn = #fn
        
        a1 oscil iamp, ifreq, ifn
        outlet a1, #output
    end_template

    template TheVerb #input #output #reverb_time
        itime = #reverb_time
        
        a1 inleta #input
        a1 reverb a1, itime
        
        outlet a1, #output
    end_template
    
    template StereoOut #left #right
        a1 inleta #left
        a2 inleta #right
        output a1, a2
    end_template

    gir ftgen 33, 0, 8192, 10, 1
    gir ftgen 34, 0, 8192, 7, -1, 8192, 1
    
    create_instr 1 MySynth "synth_out_1" 33
    create_instr 2 MySynth "synth_out_2" 34
    create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
    create_instr 4 StereoOut "synth_out_1" "verb_out"

The score:

    i 1 0 4 0.5 440  ; sine, panned hard left
    i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
    i 3 0 -1
    i 4 0 -1
    
This is only the beginning of an idea, and much more thought is required. 
Though I do believe that a system like this or similar would make Csound
much more pleasant to work with, by leaps and bounds.  Imagine having a
library with hundreds of user contributed templates / fully functional
synths that anyone can plug into their orchestras and patch into other
synths and DSPs, without the headaches of the current system.  That's the
world I want to live in.

Best,
Jake

This is a very interesting idea, and very attractive to me as a lapsed C 
programmer.  Of course, this is implementable as a separate tool without 
requiring any changes to Csound, which is cool.

For completeness, I should point out that blue's BlueSynthBuilder offers 
similar capability (though it has a different approach and the goals are 
not identical) but I don't see that as any reason not to pursue this idea.

- Dave

Jacob Joaquin wrote:
> Reusing a Csound instrument in a new score typically involves copying and
> pasting the instrument into a new orchestra.  Once pasted, the user, more
> often than not, must make modifications to the instrument in order for it to
> work in its new environment.  Sometimes it is only a matter of changing the
> instrument number.  Other times, f-tables have to be ported and renumbered
> as well.  If there are software busses involve, such as zak, then
> modifications suddenly become a minor rewrite of the instrument.
> 
> No one enjoys this.  Well, statistically speaking, I'm sure there is a
> handful of people that do.  Though as a general rule, this is tedious work
> that most Csounders would rather do without.
> 
> I propose that we develop an instrument templating system for handling,
> importing and reusing instruments.
> 
> In a nutshell, an instrument template is basically a Csound instrument,
> minus an assigned instrument number, plus it can support additional
> variables the can be designated when constructed. Here is an example of what
> a Csound instrument template might look like:
> 
>     template Sinewave440
>         a1 oscils 1, 440, 1
>         out a1
>     end_template
> 
> In this very basic example, the code in the body is 100% Csound.  This is
> important because templates should look familiar to Csounders.  Templates
> would exist in an orchestra, or in an external file.  In order to use this
> template, an instrument must be created from it.  The code to do this might
> look like this:
> 
>     create_instr 1 Sinewave440
> 
> Or if the template exists in external file:
> 
>     import_template Sinewave440 from "./foo.orc"
>     create_instr 1 Sinewave440
>     
> The instrument as it is only works when nchnls is set to one. Since
> portability is a goal, I will modify this template to make it more of a
> general purpose template.  Instead of sending a1 to the dac using out, I
> will instead send it to an audio buss using the upcoming outleta opcode.
> 
>     template Sinewave262 #output
>         a1 oscils 1, 262, 1
>         outleta a1, #output
>     end_template
> 
> Here, I introduced template arguments.  The example uses one argument,
> #output.  What ever text is supplied as the first parameter will replace
> #output in the body of the template, much like a macro.
> 
>     create_instr 1 Sinewave262 "audio_out"
>     
> After the preprocessor, the following Csound code is produced:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
> To hear the audio, we still need to create an instrument that receives the
> audio and sends it to the dac or audio file.
> 
>     template StereoOut #left_input #right_input
>         a1 inleta #left_input
>         a2 inleta #right_input
>         output a1, a2
>     end_template
> 
>     create_instr 1 Sinewave262 "audio_out"
>     create_instr 2 StereoOut "audio_out" "audio_out"
>     
> After the preprocessor, the previous code would produce the following
> orchestra code:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
>     instr 2
>         a1 inleta "audio_out"
>         a2 inleta "audio_out"
>         output a1, a2
>     endin
> 
> The greater implication is that instruments/templates could be used in a
> much more modular fashion.  Since numbers and buss names aren't assigned
> until an instr is created, Csounders would be able to patch together complex
> systems far easier and faster than is currently possible.
> 
> Here is a longer example that makes use of this theoretical patching system:
> 
>     template MySynth #output #fn
>         iamp = p4
>         ifreq = p5
>         ifn = #fn
>         
>         a1 oscil iamp, ifreq, ifn
>         outlet a1, #output
>     end_template
> 
>     template TheVerb #input #output #reverb_time
>         itime = #reverb_time
>         
>         a1 inleta #input
>         a1 reverb a1, itime
>         
>         outlet a1, #output
>     end_template
>     
>     template StereoOut #left #right
>         a1 inleta #left
>         a2 inleta #right
>         output a1, a2
>     end_template
> 
>     gir ftgen 33, 0, 8192, 10, 1
>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>     
>     create_instr 1 MySynth "synth_out_1" 33
>     create_instr 2 MySynth "synth_out_2" 34
>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>     create_instr 4 StereoOut "synth_out_1" "verb_out"
> 
> The score:
> 
>     i 1 0 4 0.5 440  ; sine, panned hard left
>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>     i 3 0 -1
>     i 4 0 -1
>     
> This is only the beginning of an idea, and much more thought is required. 
> Though I do believe that a system like this or similar would make Csound
> much more pleasant to work with, by leaps and bounds.  Imagine having a
> library with hundreds of user contributed templates / fully functional
> synths that anyone can plug into their orchestras and patch into other
> synths and DSPs, without the headaches of the current system.  That's the
> world I want to live in.
> 
> Best,
> Jake

My initial reaction is that this shouldn't be something Csound should
handle, but that's a reaction because I've already worked around
instrument encapsulation issues a long while ago in blue. blue's
system pretty much offers everything you mention but without having to
make changes to Csound itself.

With Csound alone, I think I've seen others do something similar by
just using the existing preprocessor system. Also, using named
instruments, one can just include them and as long as you make sure no
names clash, you should be alright. As for output bus, something blue
does is have a pseudo-opcode that if blue finds will handle to create
output to go to a mixer.  The instrument generates a signal based on
its instr ID, so something like ga_blue_instr_1.  A similar system
could be done using chnset and creating a string var and p1.  All
instruments then by default output values, and it is the
responsibility of the mixer instrument to gather the output.

So, basically saying I know it can be done with outside tools like
blue, and am pretty sure what you want can be done with Csound alone
as well.


On Thu, Sep 10, 2009 at 6:30 PM, Jacob Joaquin  wrote:
>
> Reusing a Csound instrument in a new score typically involves copying and
> pasting the instrument into a new orchestra.  Once pasted, the user, more
> often than not, must make modifications to the instrument in order for it to
> work in its new environment.  Sometimes it is only a matter of changing the
> instrument number.  Other times, f-tables have to be ported and renumbered
> as well.  If there are software busses involve, such as zak, then
> modifications suddenly become a minor rewrite of the instrument.
>
> No one enjoys this.  Well, statistically speaking, I'm sure there is a
> handful of people that do.  Though as a general rule, this is tedious work
> that most Csounders would rather do without.
>
> I propose that we develop an instrument templating system for handling,
> importing and reusing instruments.
>
> In a nutshell, an instrument template is basically a Csound instrument,
> minus an assigned instrument number, plus it can support additional
> variables the can be designated when constructed. Here is an example of what
> a Csound instrument template might look like:
>
>    template Sinewave440
>        a1 oscils 1, 440, 1
>        out a1
>    end_template
>
> In this very basic example, the code in the body is 100% Csound.  This is
> important because templates should look familiar to Csounders.  Templates
> would exist in an orchestra, or in an external file.  In order to use this
> template, an instrument must be created from it.  The code to do this might
> look like this:
>
>    create_instr 1 Sinewave440
>
> Or if the template exists in external file:
>
>    import_template Sinewave440 from "./foo.orc"
>    create_instr 1 Sinewave440
>
> The instrument as it is only works when nchnls is set to one. Since
> portability is a goal, I will modify this template to make it more of a
> general purpose template.  Instead of sending a1 to the dac using out, I
> will instead send it to an audio buss using the upcoming outleta opcode.
>
>    template Sinewave262 #output
>        a1 oscils 1, 262, 1
>        outleta a1, #output
>    end_template
>
> Here, I introduced template arguments.  The example uses one argument,
> #output.  What ever text is supplied as the first parameter will replace
> #output in the body of the template, much like a macro.
>
>    create_instr 1 Sinewave262 "audio_out"
>
> After the preprocessor, the following Csound code is produced:
>
>    instr 1
>        a1 oscils 1, 262, 1
>        outleta a1, "audio_out"
>    endin
>
> To hear the audio, we still need to create an instrument that receives the
> audio and sends it to the dac or audio file.
>
>    template StereoOut #left_input #right_input
>        a1 inleta #left_input
>        a2 inleta #right_input
>        output a1, a2
>    end_template
>
>    create_instr 1 Sinewave262 "audio_out"
>    create_instr 2 StereoOut "audio_out" "audio_out"
>
> After the preprocessor, the previous code would produce the following
> orchestra code:
>
>    instr 1
>        a1 oscils 1, 262, 1
>        outleta a1, "audio_out"
>    endin
>
>    instr 2
>        a1 inleta "audio_out"
>        a2 inleta "audio_out"
>        output a1, a2
>    endin
>
> The greater implication is that instruments/templates could be used in a
> much more modular fashion.  Since numbers and buss names aren't assigned
> until an instr is created, Csounders would be able to patch together complex
> systems far easier and faster than is currently possible.
>
> Here is a longer example that makes use of this theoretical patching system:
>
>    template MySynth #output #fn
>        iamp = p4
>        ifreq = p5
>        ifn = #fn
>
>        a1 oscil iamp, ifreq, ifn
>        outlet a1, #output
>    end_template
>
>    template TheVerb #input #output #reverb_time
>        itime = #reverb_time
>
>        a1 inleta #input
>        a1 reverb a1, itime
>
>        outlet a1, #output
>    end_template
>
>    template StereoOut #left #right
>        a1 inleta #left
>        a2 inleta #right
>        output a1, a2
>    end_template
>
>    gir ftgen 33, 0, 8192, 10, 1
>    gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>
>    create_instr 1 MySynth "synth_out_1" 33
>    create_instr 2 MySynth "synth_out_2" 34
>    create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>    create_instr 4 StereoOut "synth_out_1" "verb_out"
>
> The score:
>
>    i 1 0 4 0.5 440  ; sine, panned hard left
>    i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>    i 3 0 -1
>    i 4 0 -1
>
> This is only the beginning of an idea, and much more thought is required.
> Though I do believe that a system like this or similar would make Csound
> much more pleasant to work with, by leaps and bounds.  Imagine having a
> library with hundreds of user contributed templates / fully functional
> synths that anyone can plug into their orchestras and patch into other
> synths and DSPs, without the headaches of the current system.  That's the
> world I want to live in.
>
> Best,
> Jake
> --
> View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25392091.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"
>


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

It's rather easy to implement in any scripting language. I don't think 
Csound should handle this by itself.

A lot of people generate scores rather than write them by hand. 
Similarly, some people already do generate orchestra code rather than 
edit the orchestra by hand. My own system to do so use Emacs Lisp, like 
in the following code:

      (csl-play-composition
       (csound-composition
         :ftables (1 :sin 8192)
         :instr 1
         [out (oscili :arate (oscili :krate p4 1/p3 p7) p5 p6)]
         :score (insert "f 2 0 513 5 1 12 1024 500 1" ?\n)
         :i-stream
         (i 1 0 4 8000 440 1 2)
         (loop for h in '(2200 600 215 1852 990)
               for d in '(2 2.5 2 1.5 4)
               do (+i :p5 h :p3 d))))

... where the instrument specification is
	[out (oscili :arate (oscili :krate p4 1/p3 p7) p5 p6)]


regards,

Stef








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

It's interesting to see (again) that there are a number of ways to do this.
My first thought when reading the OP was that Jacob asked us to think
about a *common* template system, something that would ease instrument
exchange across different orchestras, but also between different
users. Maybe BlueShare can be used for this already (?), I mean, even
if not working in Blue?

It seems we are a bunch of "hard to standardize" people. A common
coding practice has been discussed earlier (quite some time ago), and
every now and then another idea for "common practice" comes up. It
seems we (yes, me too) are content sticking to our habits, and these
"standardization efforts" are quckly forgotten or silently ignored. I
think this is something we could discuss, if we could gain something
from e.g. a common coding practice. For one thing, porting instrument
from one orchestra to another becomes easier if they are written
accoring to some common form. Still, we have really old orchestras and
instruments (and I would not propose sticking to old ways like using
gasigs etc), and we have a number of choices for more modern signal
transport like the chn opcodes and others. It might be hard to get
everyone to agree to one specific way of doing things. But this
process need not happen overnight, if we have 50% of the users writing
in similar form to each other in 5 years from now that is a
significant step towards easier code portability across different
orchestras and users.

best
Oeyvind


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

> It seems we are a bunch of "hard to standardize" people. 

oh yes we are.. and there is not a small amount of pride in that for 
some of us (yes I'm in) :)


seriously, I agree with what you say, but it seems to me that we do not 
have that much to share so that the problem do not bite us very hard at 
the moment. we do not publish very many instruments, and even less algo 
tricks or composition tips and methods.

since we have no problem, we dont need a solution (yet). let's start 
sharing and see what kind of problems practically arise. I see no need 
for heavy conceptualization work at this stage.

regards,

Stef




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

hm, I do disagree that we don't have much to share. There's a huge
amount of Csound instruments "out there", and quite a lot of
compositions written with Csound (exclusively, or as part of a
composer tool chain). I could start listing up the resources... but
the list will be loong, your own work included. I think there's a lot
to be shared, it's just not so easily received/decoded/ported. This
keeps us inventing wheels over and over again, as many will find it
easier to implement their own than to base their instruments on
existing code.

Oeyvind

2009/9/11 Stéphane Rollandin :
> seriously, I agree with what you say, but it seems to me that we do not have
> that much to share so that the problem do not bite us very hard at the
> moment. we do not publish very many instruments, and even less algo tricks
> or composition tips and methods.


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

yes, sorry to be so unprecise. I meant sharing more like collaborating: 
we need standardization to exchange piece of code and data. all the 
instruments and composition you are talking about are self-contained and 
each of us already stydy them and take what we want (and can) from them. 
but I do not see a lot of activity in term of collaborative musical 
composition, which is where we would need strongly defined standard and 
procedures.

just my opinion, I could of course be completely wrong on this point..

regards,

Stef




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

I've spent much time collaborating with another Csounder.  The biggest issue
was having to rewrite large portions of the orchestra when merging our work,
at every step of the way.  Mostly with how the different instruments are
patched together.

Beyond collaboration, simple instrument sharing can be easy and practical. 
With templating, an orchestra becomes more than an orchestra, it becomes and
synthesizer/dsp library.  For example, if Trapped.csd was converted to
templates, then Trapped.csd is both a composition and a reusable synth/dsp
library.  As is everything else that is written with templates.  So mixing,
matching, patching between multiple orchestras becomes really simple.

    
    
    sr = 44100
    kr = 4410
    ksmps = 10
    nchnls = 1    
    0dbfs = 1.0
    
    import_template Ivory from "Trapped.csd"
    import_template Mangler from "DrumFever.csd"
    import_template MixerWithSend from "PatchTools.csd"
    import_template Rust from "Trapped.csd"
    import_template MonoOut "PatchTools.csd"
    import_template Sum from "PatchTools.csd"
    import_template SpaceVerbMono from "SpaceFX.csd"
    
    create_instr 1 Ivory "ivory_out"
    create_instr 2 Rust "rust_out"
    create_instr 3 Mangler "mangler_out"
    create_instr 4 Sum "sum_a_out" "ivory_out" "rust_out" "mangler_out"
    create_instr 5 MixerWithSend "sum_a_out" "mixer_main_out"
"mixer_send_out"
    create_instr 6 SpaceVerbMono "mixer_send_out" "verb_out"
    create_instr 7 Sum "sum_b_out" "mixer_main_out" "verb_out"
    create_instr 8 MonoOut "sum_b_out"
    
    
    ; do stuff here
    
    

Look how much could be accomplished by using shareable synth/dsp libraries. 
No copy/paste, no hardwired busses in instruments that need to be rewritten,
just quick efficient patching.  Why wouldn't we want this as part of core?

People have no problems sharing their work in other communities such as Max
and Supercollider.  Why is this?

Like I said in my original post, this is only the beginning of an idea.  We
shouldn't shoot down the idea before discussing the potential merits.  After
all, it works for Blue, right?  Well, I say what is good for Blue is good
for Csound.

In the mean time, perhaps writing a prototype script is the way to go, so we
can see it in action.  I'm guessing it'll take me about three hours to come
up with something in Python.  Just need to find three hours.  This is also
something that should not happen over night.  We should take our time and
get this write.

Best,
Jake



Stéphane Rollandin wrote:
> 
> yes, sorry to be so unprecise. I meant sharing more like collaborating: 
> we need standardization to exchange piece of code and data. all the 
> instruments and composition you are talking about are self-contained and 
> each of us already stydy them and take what we want (and can) from them. 
> but I do not see a lot of activity in term of collaborative musical 
> composition, which is where we would need strongly defined standard and 
> procedures.
> 
> just my opinion, I could of course be completely wrong on this point..
> 
> regards,
> 
> Stef
> 

-- 
View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25404988.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"

Well, the idea of reuse is sound, but the implementation is in
question.  For me, I don't see much in what you wrote that couldn't be
done using existing csound features, namely #include.  If i use named
instruments and have a descriptive name like "instr sy_fm_trpt" then
you could just #include it and use it. If you use the system mentioned
earlier from blue, then you could achieve what you want without
needing changes to csound syntax.

I'll try to create a proof of concept to demonstrate. Will reply again
once done.

steven

On Fri, Sep 11, 2009 at 1:16 PM, Jacob Joaquin  wrote:
>
> I've spent much time collaborating with another Csounder.  The biggest issue
> was having to rewrite large portions of the orchestra when merging our work,
> at every step of the way.  Mostly with how the different instruments are
> patched together.
>
> Beyond collaboration, simple instrument sharing can be easy and practical.
> With templating, an orchestra becomes more than an orchestra, it becomes and
> synthesizer/dsp library.  For example, if Trapped.csd was converted to
> templates, then Trapped.csd is both a composition and a reusable synth/dsp
> library.  As is everything else that is written with templates.  So mixing,
> matching, patching between multiple orchestras becomes really simple.
>
>    
>    
>    sr = 44100
>    kr = 4410
>    ksmps = 10
>    nchnls = 1
>    0dbfs = 1.0
>
>    import_template Ivory from "Trapped.csd"
>    import_template Mangler from "DrumFever.csd"
>    import_template MixerWithSend from "PatchTools.csd"
>    import_template Rust from "Trapped.csd"
>    import_template MonoOut "PatchTools.csd"
>    import_template Sum from "PatchTools.csd"
>    import_template SpaceVerbMono from "SpaceFX.csd"
>
>    create_instr 1 Ivory "ivory_out"
>    create_instr 2 Rust "rust_out"
>    create_instr 3 Mangler "mangler_out"
>    create_instr 4 Sum "sum_a_out" "ivory_out" "rust_out" "mangler_out"
>    create_instr 5 MixerWithSend "sum_a_out" "mixer_main_out"
> "mixer_send_out"
>    create_instr 6 SpaceVerbMono "mixer_send_out" "verb_out"
>    create_instr 7 Sum "sum_b_out" "mixer_main_out" "verb_out"
>    create_instr 8 MonoOut "sum_b_out"
>    
>    
>    ; do stuff here
>    
>    
>
> Look how much could be accomplished by using shareable synth/dsp libraries.
> No copy/paste, no hardwired busses in instruments that need to be rewritten,
> just quick efficient patching.  Why wouldn't we want this as part of core?
>
> People have no problems sharing their work in other communities such as Max
> and Supercollider.  Why is this?
>
> Like I said in my original post, this is only the beginning of an idea.  We
> shouldn't shoot down the idea before discussing the potential merits.  After
> all, it works for Blue, right?  Well, I say what is good for Blue is good
> for Csound.
>
> In the mean time, perhaps writing a prototype script is the way to go, so we
> can see it in action.  I'm guessing it'll take me about three hours to come
> up with something in Python.  Just need to find three hours.  This is also
> something that should not happen over night.  We should take our time and
> get this write.
>
> Best,
> Jake
>
>
>
> Stéphane Rollandin wrote:
>>
>> yes, sorry to be so unprecise. I meant sharing more like collaborating:
>> we need standardization to exchange piece of code and data. all the
>> instruments and composition you are talking about are self-contained and
>> each of us already stydy them and take what we want (and can) from them.
>> but I do not see a lot of activity in term of collaborative musical
>> composition, which is where we would need strongly defined standard and
>> procedures.
>>
>> just my opinion, I could of course be completely wrong on this point..
>>
>> regards,
>>
>> Stef
>>
>
> --
> View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25404988.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"


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

Attached is a proof of concept.  It has:

1. Instrument definitions in their own files

2. Resources for instrument encapsulated within the instrument (as
discussed in http://www.csounds.com/journal/2006winter/encapsulatedInstruments.html)

3. Main CSD file that includes the instrument to use and has a Mixer
instrument. The mixer instrument uses the conventions followed by the
instruments.  Instruments were designed to send out their signals to
chnset using "_" so for instr sy_test1 it
published its signal as "sy_test1_0" and "sy_test1_1", similarly for
sy_test2 instrument. The mixer instrument is free to mix and match the
signals as desired, and signal processing code can be inserted
anywhere in the chain.

This is close to how blue does it's mixer system and encapsulation,
though some things are a little more convenient for blue to allow
easier writing of things while blue handles converting to uglier but
safe code.  Blue's effects system that works with it's mixer is done
generating UDO per effect, and signals in the mixer instrument are run
through the UDO.

The attached code should allow most of what you are looking for using
existing Csound features.  If you want to have the ability to assign
instr numbers, then you'd have to convert instr definition files to
wrap with a macro definition, then both #include as well as call the
macro with a number to replace into the instrument definition.  If you
do that, you'll have to modify somewhat the name of the signal being
generated from that instrument, but that's fairly straightforward.

I'd recommend doing something like this as any program working with
Csound should be able to exchange these kinds of instruments around.

steven

On Fri, Sep 11, 2009 at 1:44 PM, Steven Yi  wrote:
> Well, the idea of reuse is sound, but the implementation is in
> question.  For me, I don't see much in what you wrote that couldn't be
> done using existing csound features, namely #include.  If i use named
> instruments and have a descriptive name like "instr sy_fm_trpt" then
> you could just #include it and use it. If you use the system mentioned
> earlier from blue, then you could achieve what you want without
> needing changes to csound syntax.
>
> I'll try to create a proof of concept to demonstrate. Will reply again
> once done.
>
> steven
>
> On Fri, Sep 11, 2009 at 1:16 PM, Jacob Joaquin  wrote:
>>
>> I've spent much time collaborating with another Csounder.  The biggest issue
>> was having to rewrite large portions of the orchestra when merging our work,
>> at every step of the way.  Mostly with how the different instruments are
>> patched together.
>>
>> Beyond collaboration, simple instrument sharing can be easy and practical.
>> With templating, an orchestra becomes more than an orchestra, it becomes and
>> synthesizer/dsp library.  For example, if Trapped.csd was converted to
>> templates, then Trapped.csd is both a composition and a reusable synth/dsp
>> library.  As is everything else that is written with templates.  So mixing,
>> matching, patching between multiple orchestras becomes really simple.
>>
>>    
>>    
>>    sr = 44100
>>    kr = 4410
>>    ksmps = 10
>>    nchnls = 1
>>    0dbfs = 1.0
>>
>>    import_template Ivory from "Trapped.csd"
>>    import_template Mangler from "DrumFever.csd"
>>    import_template MixerWithSend from "PatchTools.csd"
>>    import_template Rust from "Trapped.csd"
>>    import_template MonoOut "PatchTools.csd"
>>    import_template Sum from "PatchTools.csd"
>>    import_template SpaceVerbMono from "SpaceFX.csd"
>>
>>    create_instr 1 Ivory "ivory_out"
>>    create_instr 2 Rust "rust_out"
>>    create_instr 3 Mangler "mangler_out"
>>    create_instr 4 Sum "sum_a_out" "ivory_out" "rust_out" "mangler_out"
>>    create_instr 5 MixerWithSend "sum_a_out" "mixer_main_out"
>> "mixer_send_out"
>>    create_instr 6 SpaceVerbMono "mixer_send_out" "verb_out"
>>    create_instr 7 Sum "sum_b_out" "mixer_main_out" "verb_out"
>>    create_instr 8 MonoOut "sum_b_out"
>>    
>>    
>>    ; do stuff here
>>    
>>    
>>
>> Look how much could be accomplished by using shareable synth/dsp libraries.
>> No copy/paste, no hardwired busses in instruments that need to be rewritten,
>> just quick efficient patching.  Why wouldn't we want this as part of core?
>>
>> People have no problems sharing their work in other communities such as Max
>> and Supercollider.  Why is this?
>>
>> Like I said in my original post, this is only the beginning of an idea.  We
>> shouldn't shoot down the idea before discussing the potential merits.  After
>> all, it works for Blue, right?  Well, I say what is good for Blue is good
>> for Csound.
>>
>> In the mean time, perhaps writing a prototype script is the way to go, so we
>> can see it in action.  I'm guessing it'll take me about three hours to come
>> up with something in Python.  Just need to find three hours.  This is also
>> something that should not happen over night.  We should take our time and
>> get this write.
>>
>> Best,
>> Jake
>>
>>
>>
>> Stéphane Rollandin wrote:
>>>
>>> yes, sorry to be so unprecise. I meant sharing more like collaborating:
>>> we need standardization to exchange piece of code and data. all the
>>> instruments and composition you are talking about are self-contained and
>>> each of us already stydy them and take what we want (and can) from them.
>>> but I do not see a lot of activity in term of collaborative musical
>>> composition, which is where we would need strongly defined standard and
>>> procedures.
>>>
>>> just my opinion, I could of course be completely wrong on this point..
>>>
>>> regards,
>>>
>>> Stef
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25404988.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"
>

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

I'm not implying Csound can't do these things already.  I'm just saying that
all of the solutions I've seen over the years, including my own multiple
attempts, are overly complicated, hackish, and absolutely not conducive to
an environment for creating shareable instruments.

There is also the human factor.  Oeyvind put it perfectly, "It seems we are
a bunch of 'hard to standardize' people."  We just can't present a set of
common practices and/or a collection of methods for implementing existing
Csound features and expect people adapt them.  That has been tried, it
doesn't work.  I also have serious doubts that someone new to Csound could
follow along.  At least templates would give new Csounders a sporting
chance, since a template is more or less a Csound instrument with a handful
of parameters.

Named instruments don't work, because as of now, i statements only support
one string, which includes the name of the instrument.  Bad if one needs to
specify the name of an audio file in the score.  Even using macro
definitions to assign numbers creates its own set of probables in the
namespace category.  What if someone tries to include two different
instruments from two different files that have identical macro names?  One
could go and make changes to the code - but that is the exact type of
pitfall which I'm advocating we do away with.  If you have to touch the code
to port it, then the implementation is wrong.  With templates, we can bypass
this problem:

    import_template Cello from "./etude1.csd"
    import_template Cello from "./etude2.csd" as Cello2
    
Not to mention, multiple templates could co-exist in the same file, and can
be directly imported from a composition. #include could not do this.

Best,
Jake



Steven Yi wrote:
> 
> Attached is a proof of concept.  It has:
> 
> 1. Instrument definitions in their own files
> 
> 2. Resources for instrument encapsulated within the instrument (as
> discussed in
> http://www.csounds.com/journal/2006winter/encapsulatedInstruments.html)
> 
> 3. Main CSD file that includes the instrument to use and has a Mixer
> instrument. The mixer instrument uses the conventions followed by the
> instruments.  Instruments were designed to send out their signals to
> chnset using "_" so for instr sy_test1 it
> published its signal as "sy_test1_0" and "sy_test1_1", similarly for
> sy_test2 instrument. The mixer instrument is free to mix and match the
> signals as desired, and signal processing code can be inserted
> anywhere in the chain.
> 
> This is close to how blue does it's mixer system and encapsulation,
> though some things are a little more convenient for blue to allow
> easier writing of things while blue handles converting to uglier but
> safe code.  Blue's effects system that works with it's mixer is done
> generating UDO per effect, and signals in the mixer instrument are run
> through the UDO.
> 
> The attached code should allow most of what you are looking for using
> existing Csound features.  If you want to have the ability to assign
> instr numbers, then you'd have to convert instr definition files to
> wrap with a macro definition, then both #include as well as call the
> macro with a number to replace into the instrument definition.  If you
> do that, you'll have to modify somewhat the name of the signal being
> generated from that instrument, but that's fairly straightforward.
> 
> I'd recommend doing something like this as any program working with
> Csound should be able to exchange these kinds of instruments around.
> 

You make some good points.  Again, these are mostly problems I've
solved for myself in blue a while ago so I'm not finding this a
pressing concern, but I can see where you're coming from.

If you really want an import system in syntax, then I'd recommend
changing things a bit from your recommendation.  The issue I see is
that the definition of an instrument and the assignment to a number or
name is a singular thing in csound today.  From what I understand your
changes are basically to make instr like a class and to split
assignment and definition.  To be backwards compatible, instr could be
something like this:

; define an instrument type
instrdef instrDefName

endinstrdef

;assign that to an id
instr id "instrDefName"

;assign id to anonymous instrument definition
instr id
  anonymous instrument definition
endin


I'd drop the _template and just have import be a keyword.

It'd be useful then to create a namespace system so that resources can
be contained.

If we go this far, we will gain making csound a bit more
object-oriented in nature, yet should still be backwards compatible to
loading older projects.

I think we would have to go at least this far if there's any chance of
making a real encapsulation system, but I think this is non-trivial
and all code looking up values would have to be modified to be
namespace aware.  (This may not be so bad to implement though, I
haven't looked at this in a long while and it may be something that
can be updated in a few utility functions).

There are a couple other things I'd rather see first, like calling
UDO's or opcodes as functions and live manipulation of instruments
already defined in memory, but I could go along with the above.

steven

On Fri, Sep 11, 2009 at 4:15 PM, Jacob Joaquin  wrote:
>
> I'm not implying Csound can't do these things already.  I'm just saying that
> all of the solutions I've seen over the years, including my own multiple
> attempts, are overly complicated, hackish, and absolutely not conducive to
> an environment for creating shareable instruments.
>
> There is also the human factor.  Oeyvind put it perfectly, "It seems we are
> a bunch of 'hard to standardize' people."  We just can't present a set of
> common practices and/or a collection of methods for implementing existing
> Csound features and expect people adapt them.  That has been tried, it
> doesn't work.  I also have serious doubts that someone new to Csound could
> follow along.  At least templates would give new Csounders a sporting
> chance, since a template is more or less a Csound instrument with a handful
> of parameters.
>
> Named instruments don't work, because as of now, i statements only support
> one string, which includes the name of the instrument.  Bad if one needs to
> specify the name of an audio file in the score.  Even using macro
> definitions to assign numbers creates its own set of probables in the
> namespace category.  What if someone tries to include two different
> instruments from two different files that have identical macro names?  One
> could go and make changes to the code - but that is the exact type of
> pitfall which I'm advocating we do away with.  If you have to touch the code
> to port it, then the implementation is wrong.  With templates, we can bypass
> this problem:
>
>    import_template Cello from "./etude1.csd"
>    import_template Cello from "./etude2.csd" as Cello2
>
> Not to mention, multiple templates could co-exist in the same file, and can
> be directly imported from a composition. #include could not do this.
>
> Best,
> Jake
>
>
>
> Steven Yi wrote:
>>
>> Attached is a proof of concept.  It has:
>>
>> 1. Instrument definitions in their own files
>>
>> 2. Resources for instrument encapsulated within the instrument (as
>> discussed in
>> http://www.csounds.com/journal/2006winter/encapsulatedInstruments.html)
>>
>> 3. Main CSD file that includes the instrument to use and has a Mixer
>> instrument. The mixer instrument uses the conventions followed by the
>> instruments.  Instruments were designed to send out their signals to
>> chnset using "_" so for instr sy_test1 it
>> published its signal as "sy_test1_0" and "sy_test1_1", similarly for
>> sy_test2 instrument. The mixer instrument is free to mix and match the
>> signals as desired, and signal processing code can be inserted
>> anywhere in the chain.
>>
>> This is close to how blue does it's mixer system and encapsulation,
>> though some things are a little more convenient for blue to allow
>> easier writing of things while blue handles converting to uglier but
>> safe code.  Blue's effects system that works with it's mixer is done
>> generating UDO per effect, and signals in the mixer instrument are run
>> through the UDO.
>>
>> The attached code should allow most of what you are looking for using
>> existing Csound features.  If you want to have the ability to assign
>> instr numbers, then you'd have to convert instr definition files to
>> wrap with a macro definition, then both #include as well as call the
>> macro with a number to replace into the instrument definition.  If you
>> do that, you'll have to modify somewhat the name of the signal being
>> generated from that instrument, but that's fairly straightforward.
>>
>> I'd recommend doing something like this as any program working with
>> Csound should be able to exchange these kinds of instruments around.
>>
>
> --
> View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25407671.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"
>


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

> Look how much could be accomplished by using shareable synth/dsp libraries. 
> No copy/paste, no hardwired busses in instruments that need to be rewritten,
> just quick efficient patching.  Why wouldn't we want this as part of core?

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.

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 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.

This of course leaves intact the problem of sharing instruments and 
set-ups. But I have my solution: it's Csound-X. You just have to use 
Emacs and learn my system :) Of course others have their own system, 
which I did not learn... So we are left with this deep truth: we are
a bunch of 'hard to standardize' people. There is a reason for this: our 
creativity applies to the full chain, from high-level code for musical 
composition down to assembly-like DSP for sound. It sure would be nice 
to have some standard for sharing code, but if this standard gets in the 
way of a composer's workflow, it will not be used: it will be seen as a 
hack. Another deep truth, maybe: a man's solution is another man's hack.


best,

Stef






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

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"

I'm not sure if this is clear, so just in case.  The system I'm proposing
doesn't change Csound, it just appends it.  I'm well aware that Csound's
mantra is "Do not break backwards compatibility.  No compromise.  Even in
the face of Armageddon."

Also, the syntax/keywords I've provided I'm not even sold on, and I expect
these types of issues to evolve.  I'm just trying to explain how a system
might function, and provide a more user-friendly experience.  So if we want
to call them classes instead of templates, import instead of
import_template, that's not even an issue with me.  My only concern is that
any system implemented should look and feel like Csound.

We may or not be in agreement, but I think we're at least on the same page
now.  And UDOs/opcodes as functions and live manipulations of instruments
would be wonderful!  I'm not opposed to seeing those things happen first.

Best,
Jake



Steven Yi wrote:
> 
> You make some good points.  Again, these are mostly problems I've
> solved for myself in blue a while ago so I'm not finding this a
> pressing concern, but I can see where you're coming from.
> 
> If you really want an import system in syntax, then I'd recommend
> changing things a bit from your recommendation.  The issue I see is
> that the definition of an instrument and the assignment to a number or
> name is a singular thing in csound today.  From what I understand your
> changes are basically to make instr like a class and to split
> assignment and definition.  To be backwards compatible, instr could be
> something like this:
> 
> ; define an instrument type
> instrdef instrDefName
> 
> endinstrdef
> 
> ;assign that to an id
> instr id "instrDefName"
> 
> ;assign id to anonymous instrument definition
> instr id
>   anonymous instrument definition
> endin
> 
> 
> I'd drop the _template and just have import be a keyword.
> 
> It'd be useful then to create a namespace system so that resources can
> be contained.
> 
> If we go this far, we will gain making csound a bit more
> object-oriented in nature, yet should still be backwards compatible to
> loading older projects.
> 
> I think we would have to go at least this far if there's any chance of
> making a real encapsulation system, but I think this is non-trivial
> and all code looking up values would have to be modified to be
> namespace aware.  (This may not be so bad to implement though, I
> haven't looked at this in a long while and it may be something that
> can be updated in a few utility functions).
> 
> There are a couple other things I'd rather see first, like calling
> UDO's or opcodes as functions and live manipulation of instruments
> already defined in memory, but I could go along with the above.
> 
> steven
> 

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"

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"

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"

I think you read my mind.  Our syntax and metaphors maybe different, but the
underlying concepts are very similar.

Best,
Jake



Michael Gogins-2 wrote:
> 
> 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"
> 

-- 
View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25417340.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"

There is one thing I'm not seeing, and that is the ability to define an
instrument abstraction/class/template, then instantiating a working
instrument/block from the abstraction.  Is this the case?

For example, if I wanted to use a second copy of "toot" from your example,
is there something that allows me to create a second instance in the
orchestra?

Best,
Jake



Michael Gogins-2 wrote:
> 
> 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"
> 

My thoughts are that we could keep this really simple, that is, execution
order is determined by the order in which instruments are created.  In this
scenario, a programmer will know the order just by scanning the orchestra
from top to bottom.  If execution order is determined by which inlets are
patched into what outlets, etc., then that could potentially be confusing to
the programmer.

    ; Cat, Dog, Mouse are all classes
    create_instr "cat_1" from Cat
    create_instr "dog_1" from Dob
    create_instr "cat_2" from Cat
    create_instr "mouse_1" from Mouse

Here, we can quicly scan to see that the execution order is: cat_1, dog_1,
cat_2, mouse_1.

One of the reasons to move to abstract instr classes is that they have no
assigned number, are not part of any graph, and do not have to be defined in
any particular order.  Only when an instr is created from a class does that
instr instance become part of a graph and assigned its position in the
execution chain.  This allows great flexibility in terms of both the
creation of graphs and importing abstract instr classes from other files. 
Multiple instrs can be created from the same class, with each of these
instances being given a different slot in the execution order.  The names of
the inlet/outlet busses would be also be assigned, by the coder, when an
instr is created from a class.
 

Michael Gogins-2 wrote:
> 
> 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.
> 

Best,
Jake

I built a prototype in python.  It's about as barebones and fugly as it gets,
but it works.

I want to briefly describe what this prototype does.  Instead of creating
instrs in the orchestra, I created classes.  Writing a class is nearly
identical to writing an instr.  A class by itself does nothing.  An instr
must be created from a class for it to be useful.  Multiple instrs can be
created from the same class, with each instr being assigned its own unique
instr number.  Classes support optional arguments, with the values of the
arguments being assigned when instrs are created.

In the examples listed near the bottom of this post, I designed the classes
so that the optional arguments are the names of chn input and output busses. 
This allowed me to patch instrs as I create them, instead of hardwiring them
directly inside of instr blocks.

The first example is fairly straight forward.  The Basic class, when
created, generates an enveloped sine wave, and is written to the chn buss
"basic_1".  The instance of MonoOut taps "basic_1" and sends it to the out
opcode.  The final class, Clear, is used to clear the chn buss "basic_1" so
that feedback does not occur.  This won't be an issue once inlet/outlet
opcodes are released as part of a future version of Csound.

Example 1 before being processed:
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd

Example 1 after being processed (Csound can render this):
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd


The second example builds off the first, and demonstrates how multiple
instances of the same class can be built.  Two instances of Basic2 and
MonoVerb are created, with each having its own unique instr number and
unique chn buss input/output names.  

Example 2 before being processed:
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd

Example 2 after being processed (Csound can render this):
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd


You can download all the files here, including the python file that
preprocesses the classes:
http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip


I'll keep working on this in my spare time.  I'm going to incorporate it
into my CSD python package, and put everything up at sourceforge or google
code sometime in the next couple of weeks.  I'll keep everyone posted.

Best,
Jake 



Jacob Joaquin wrote:
> 
> Reusing a Csound instrument in a new score typically involves copying and
> pasting the instrument into a new orchestra.  Once pasted, the user, more
> often than not, must make modifications to the instrument in order for it
> to work in its new environment.  Sometimes it is only a matter of changing
> the instrument number.  Other times, f-tables have to be ported and
> renumbered as well.  If there are software busses involve, such as zak,
> then modifications suddenly become a minor rewrite of the instrument.
> 
> No one enjoys this.  Well, statistically speaking, I'm sure there is a
> handful of people that do.  Though as a general rule, this is tedious work
> that most Csounders would rather do without.
> 
> I propose that we develop an instrument templating system for handling,
> importing and reusing instruments.
> 
> In a nutshell, an instrument template is basically a Csound instrument,
> minus an assigned instrument number, plus it can support additional
> variables the can be designated when constructed. Here is an example of
> what a Csound instrument template might look like:
> 
>     template Sinewave440
>         a1 oscils 1, 440, 1
>         out a1
>     end_template
> 
> In this very basic example, the code in the body is 100% Csound.  This is
> important because templates should look familiar to Csounders.  Templates
> would exist in an orchestra, or in an external file.  In order to use this
> template, an instrument must be created from it.  The code to do this
> might look like this:
> 
>     create_instr 1 Sinewave440
> 
> Or if the template exists in external file:
> 
>     import_template Sinewave440 from "./foo.orc"
>     create_instr 1 Sinewave440
>     
> The instrument as it is only works when nchnls is set to one. Since
> portability is a goal, I will modify this template to make it more of a
> general purpose template.  Instead of sending a1 to the dac using out, I
> will instead send it to an audio buss using the upcoming outleta opcode.
> 
>     template Sinewave262 #output
>         a1 oscils 1, 262, 1
>         outleta a1, #output
>     end_template
> 
> Here, I introduced template arguments.  The example uses one argument,
> #output.  What ever text is supplied as the first parameter will replace
> #output in the body of the template, much like a macro.
> 
>     create_instr 1 Sinewave262 "audio_out"
>     
> After the preprocessor, the following Csound code is produced:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
> To hear the audio, we still need to create an instrument that receives the
> audio and sends it to the dac or audio file.
> 
>     template StereoOut #left_input #right_input
>         a1 inleta #left_input
>         a2 inleta #right_input
>         output a1, a2
>     end_template
> 
>     create_instr 1 Sinewave262 "audio_out"
>     create_instr 2 StereoOut "audio_out" "audio_out"
>     
> After the preprocessor, the previous code would produce the following
> orchestra code:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
>     instr 2
>         a1 inleta "audio_out"
>         a2 inleta "audio_out"
>         output a1, a2
>     endin
> 
> The greater implication is that instruments/templates could be used in a
> much more modular fashion.  Since numbers and buss names aren't assigned
> until an instr is created, Csounders would be able to patch together
> complex systems far easier and faster than is currently possible.
> 
> Here is a longer example that makes use of this theoretical patching
> system:
> 
>     template MySynth #output #fn
>         iamp = p4
>         ifreq = p5
>         ifn = #fn
>         
>         a1 oscil iamp, ifreq, ifn
>         outlet a1, #output
>     end_template
> 
>     template TheVerb #input #output #reverb_time
>         itime = #reverb_time
>         
>         a1 inleta #input
>         a1 reverb a1, itime
>         
>         outlet a1, #output
>     end_template
>     
>     template StereoOut #left #right
>         a1 inleta #left
>         a2 inleta #right
>         output a1, a2
>     end_template
> 
>     gir ftgen 33, 0, 8192, 10, 1
>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>     
>     create_instr 1 MySynth "synth_out_1" 33
>     create_instr 2 MySynth "synth_out_2" 34
>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>     create_instr 4 StereoOut "synth_out_1" "verb_out"
> 
> The score:
> 
>     i 1 0 4 0.5 440  ; sine, panned hard left
>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>     i 3 0 -1
>     i 4 0 -1
>     
> This is only the beginning of an idea, and much more thought is required. 
> Though I do believe that a system like this or similar would make Csound
> much more pleasant to work with, by leaps and bounds.  Imagine having a
> library with hundreds of user contributed templates / fully functional
> synths that anyone can plug into their orchestras and patch into other
> synths and DSPs, without the headaches of the current system.  That's the
> world I want to live in.
> 
> Best,
> Jake
> 

Let me summarize what I understand:

You propose here a meta syntax to be processed by an external engine in 
order to be converted into a plain CSD. If this is accepted as a 
standard, then Csound front-ends implementors would be responsible for 
providing the external engine. You would provide Python script, I would 
provide Emacs Lisp code in Csound-X, etc. Is it right ?

I see no problem with this approach, other than defining a comprehensive 
standard agreed upon by everybody. If such a standard (doomed to become 
over time an actual language IMO, probably much more complex than your 
current draft) is indeed defined, I would be pleased to extend Csound-X 
so that it gets supported.

Or should the processing be done by a Csound binary utility delivered as 
part of the Csound distribution ?

What do others think ?


Stef




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

Thinking about it, I see two pitfalls about the meta-syntax idea: either 
it is to be implemented by each front-end, in which case developers will 
be tempted to extend the syntax by themselves, and interoperability may 
suffer (e.g. a file could be processed by some front-ends but not all), 
or the processing engine is to be implemented in C and shipped with 
Csound, in which case the specification for the meta-syntax is going to 
become a non-trivial activity on this list, and someone has to become 
the responsible for the actual coding.

You idea seems good, but it is actually very ambitious if we want to 
explore it seriously. Lots of work ahead.


Stef




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

I guess what I'm proposing is that we define a specification, implement this
specification in an external engine such as a Python module, until it is
refined enough to become part of Csound.  Not something to take lightly for
sure, and I expect this will take much trial and error if we are to get it
right.

Best,
Jake



Stéphane Rollandin wrote:
> 
> Let me summarize what I understand:
> 
> You propose here a meta syntax to be processed by an external engine in 
> order to be converted into a plain CSD. If this is accepted as a 
> standard, then Csound front-ends implementors would be responsible for 
> providing the external engine. You would provide Python script, I would 
> provide Emacs Lisp code in Csound-X, etc. Is it right ?
> 
> I see no problem with this approach, other than defining a comprehensive 
> standard agreed upon by everybody. If such a standard (doomed to become 
> over time an actual language IMO, probably much more complex than your 
> current draft) is indeed defined, I would be pleased to extend Csound-X 
> so that it gets supported.
> 
> Or should the processing be done by a Csound binary utility delivered as 
> part of the Csound distribution ?
> 
> What do others think ?
> 
> 
> Stef
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25428127.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"

> I guess what I'm proposing is that we define a specification, implement this
> specification in an external engine such as a Python module, until it is
> refined enough to become part of Csound.  Not something to take lightly for
> sure, and I expect this will take much trial and error if we are to get it
> right.

this is a cost-less approach, so I see no problem with it.

now, if no consensus can be found, nothing prevents you from developping 
your Python scripts in any direction you like: you will not be bothered 
by endless discussion to convince others, instead just provide your 
independent set of tools for anyone to use. this is what I do with 
Emacs, and as I said earlier it feels to me like the right approach: 
keep the actual Csound syntax as an assembly-like language, and design 
high-level languages/metaphors above it.

in that context, what we should strive for in Csound itself is true 
functionality extension, like what Mike Gogins is doing right now with 
his new opcodes. he just adds raw power to the core language, while we 
add flexibility and high-level modularity via external preprocessing 
languages.

does this make sense ?


Stef




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

I do like the idea of doing this inside Csound, with no dependency on
an external language. I also think that Michaels proposed strategy
might provide us with tools for easier patching of signals in an
orchestra, even for situations where we code in Csound without having
in mind that we want to share the instruments. I also seems like this
proposed strategy could be useful when we start thinking more about
runtime dynamic instruments. It also seems like Jacob has given this a
lot of thought, and have considered a number of requirements for this
to work in practice. It would be of great value if these efforts could
be merged into one strategy.

I've attached a simple "patchcord csd", for what it's worth. It's
probably way too simple, and you have certainly thought of this way of
using macros already. ... and it's only related to dynamic signal
patching using excisting Csound opcodes. But here it is anyway.
If we had a way of recognizing the number of arguments to a macro, it
would be relatively easy to expand this to allow arbitrary number of
inputs and outputs for a "patch cord".

Oeyvind


2009/9/12 Michael Gogins :
> 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"

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

Hi all,
Makes sense to me to separate core source-code activity from super- 
structural components, though cost-lessness is not necessarily the  
only, or even most important, criteria.

Some other comments:
1. I would separate score and synthesis development, keeping backward  
compat. incl. score pre-processing.

2. If wanting to apply same logic/restriction to these newer ideas,  
developers should invoke such separation to other efforts [Maccound,  
Blue, Cutesound, etc] for logical clarity but should encourage  
communication for those interested in such developments, perhaps  make  
separate sections of [website, cvs, etc] so as to encourage such  
developments.

3. Consistency of reasons for inclusions/exclusions in core packages  
is vital. That means resisting the appeal to "please could  
[developers] include X, Y and Z in the auto package" when it is more  
consistent to keep them separate. Not to do so keeps csound might make  
it easier for some subgroups of users but keeps it firmly in the  
domain of nerdville.

ciao4now,
David

On 14/09/2009, at 5:40 PM, Stéphane Rollandin wrote:

>> I guess what I'm proposing is that we define a specification,  
>> implement this
>> specification in an external engine such as a Python module, until  
>> it is
>> refined enough to become part of Csound.  Not something to take  
>> lightly for
>> sure, and I expect this will take much trial and error if we are to  
>> get it
>> right.
>
> this is a cost-less approach, so I see no problem with it.
>
> now, if no consensus can be found, nothing prevents you from  
> developping your Python scripts in any direction you like: you will  
> not be bothered by endless discussion to convince others, instead  
> just provide your independent set of tools for anyone to use. this  
> is what I do with Emacs, and as I said earlier it feels to me like  
> the right approach: keep the actual Csound syntax as an assembly- 
> like language, and design high-level languages/metaphors above it.
>
> in that context, what we should strive for in Csound itself is true  
> functionality extension, like what Mike Gogins is doing right now  
> with his new opcodes. he just adds raw power to the core language,  
> while we add flexibility and high-level modularity via external  
> preprocessing languages.
>
> does this make sense ?
>
>
> Stef
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"




________________________________________________
Dr David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au








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

I like this example a lot, it makes it a lot easier to do things like 
reverb without putting it in an instrument. But as a programmer I wonder 
immediately if using these strings is efficient; looking up a string is 
slower than looking up a number; but maybe this is taken care of when 
compiling the orchestra and score.

After reading Victors article in the latest CSound journal, I thought 
about writing the core of instruments in a UDO, so it is easier to use 
it with both MIDI parameters and volume+pitch, by having a simple 
instrument that transforms MIDI parameters into volume and pitch and 
calls the UDO with these. But you could do the same with the mechanism 
you propose here.

Mark

Jacob Joaquin wrote:
> I built a prototype in python.  It's about as barebones and fugly as it gets,
> but it works.
>
> I want to briefly describe what this prototype does.  Instead of creating
> instrs in the orchestra, I created classes.  Writing a class is nearly
> identical to writing an instr.  A class by itself does nothing.  An instr
> must be created from a class for it to be useful.  Multiple instrs can be
> created from the same class, with each instr being assigned its own unique
> instr number.  Classes support optional arguments, with the values of the
> arguments being assigned when instrs are created.
>
> In the examples listed near the bottom of this post, I designed the classes
> so that the optional arguments are the names of chn input and output busses. 
> This allowed me to patch instrs as I create them, instead of hardwiring them
> directly inside of instr blocks.
>
> The first example is fairly straight forward.  The Basic class, when
> created, generates an enveloped sine wave, and is written to the chn buss
> "basic_1".  The instance of MonoOut taps "basic_1" and sends it to the out
> opcode.  The final class, Clear, is used to clear the chn buss "basic_1" so
> that feedback does not occur.  This won't be an issue once inlet/outlet
> opcodes are released as part of a future version of Csound.
>
> Example 1 before being processed:
> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd
>
> Example 1 after being processed (Csound can render this):
> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd
>
>
> The second example builds off the first, and demonstrates how multiple
> instances of the same class can be built.  Two instances of Basic2 and
> MonoVerb are created, with each having its own unique instr number and
> unique chn buss input/output names.  
>
> Example 2 before being processed:
> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd
>
> Example 2 after being processed (Csound can render this):
> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd
>
>
> You can download all the files here, including the python file that
> preprocesses the classes:
> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip
>
>
> I'll keep working on this in my spare time.  I'm going to incorporate it
> into my CSD python package, and put everything up at sourceforge or google
> code sometime in the next couple of weeks.  I'll keep everyone posted.
>
> Best,
> Jake 
>
>
>
> Jacob Joaquin wrote:
>   
>> Reusing a Csound instrument in a new score typically involves copying and
>> pasting the instrument into a new orchestra.  Once pasted, the user, more
>> often than not, must make modifications to the instrument in order for it
>> to work in its new environment.  Sometimes it is only a matter of changing
>> the instrument number.  Other times, f-tables have to be ported and
>> renumbered as well.  If there are software busses involve, such as zak,
>> then modifications suddenly become a minor rewrite of the instrument.
>>
>> No one enjoys this.  Well, statistically speaking, I'm sure there is a
>> handful of people that do.  Though as a general rule, this is tedious work
>> that most Csounders would rather do without.
>>
>> I propose that we develop an instrument templating system for handling,
>> importing and reusing instruments.
>>
>> In a nutshell, an instrument template is basically a Csound instrument,
>> minus an assigned instrument number, plus it can support additional
>> variables the can be designated when constructed. Here is an example of
>> what a Csound instrument template might look like:
>>
>>     template Sinewave440
>>         a1 oscils 1, 440, 1
>>         out a1
>>     end_template
>>
>> In this very basic example, the code in the body is 100% Csound.  This is
>> important because templates should look familiar to Csounders.  Templates
>> would exist in an orchestra, or in an external file.  In order to use this
>> template, an instrument must be created from it.  The code to do this
>> might look like this:
>>
>>     create_instr 1 Sinewave440
>>
>> Or if the template exists in external file:
>>
>>     import_template Sinewave440 from "./foo.orc"
>>     create_instr 1 Sinewave440
>>     
>> The instrument as it is only works when nchnls is set to one. Since
>> portability is a goal, I will modify this template to make it more of a
>> general purpose template.  Instead of sending a1 to the dac using out, I
>> will instead send it to an audio buss using the upcoming outleta opcode.
>>
>>     template Sinewave262 #output
>>         a1 oscils 1, 262, 1
>>         outleta a1, #output
>>     end_template
>>
>> Here, I introduced template arguments.  The example uses one argument,
>> #output.  What ever text is supplied as the first parameter will replace
>> #output in the body of the template, much like a macro.
>>
>>     create_instr 1 Sinewave262 "audio_out"
>>     
>> After the preprocessor, the following Csound code is produced:
>>
>>     instr 1
>>         a1 oscils 1, 262, 1
>>         outleta a1, "audio_out"
>>     endin
>>
>> To hear the audio, we still need to create an instrument that receives the
>> audio and sends it to the dac or audio file.
>>
>>     template StereoOut #left_input #right_input
>>         a1 inleta #left_input
>>         a2 inleta #right_input
>>         output a1, a2
>>     end_template
>>
>>     create_instr 1 Sinewave262 "audio_out"
>>     create_instr 2 StereoOut "audio_out" "audio_out"
>>     
>> After the preprocessor, the previous code would produce the following
>> orchestra code:
>>
>>     instr 1
>>         a1 oscils 1, 262, 1
>>         outleta a1, "audio_out"
>>     endin
>>
>>     instr 2
>>         a1 inleta "audio_out"
>>         a2 inleta "audio_out"
>>         output a1, a2
>>     endin
>>
>> The greater implication is that instruments/templates could be used in a
>> much more modular fashion.  Since numbers and buss names aren't assigned
>> until an instr is created, Csounders would be able to patch together
>> complex systems far easier and faster than is currently possible.
>>
>> Here is a longer example that makes use of this theoretical patching
>> system:
>>
>>     template MySynth #output #fn
>>         iamp = p4
>>         ifreq = p5
>>         ifn = #fn
>>         
>>         a1 oscil iamp, ifreq, ifn
>>         outlet a1, #output
>>     end_template
>>
>>     template TheVerb #input #output #reverb_time
>>         itime = #reverb_time
>>         
>>         a1 inleta #input
>>         a1 reverb a1, itime
>>         
>>         outlet a1, #output
>>     end_template
>>     
>>     template StereoOut #left #right
>>         a1 inleta #left
>>         a2 inleta #right
>>         output a1, a2
>>     end_template
>>
>>     gir ftgen 33, 0, 8192, 10, 1
>>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>>     
>>     create_instr 1 MySynth "synth_out_1" 33
>>     create_instr 2 MySynth "synth_out_2" 34
>>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>>     create_instr 4 StereoOut "synth_out_1" "verb_out"
>>
>> The score:
>>
>>     i 1 0 4 0.5 440  ; sine, panned hard left
>>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>>     i 3 0 -1
>>     i 4 0 -1
>>     
>> This is only the beginning of an idea, and much more thought is required. 
>> Though I do believe that a system like this or similar would make Csound
>> much more pleasant to work with, by leaps and bounds.  Imagine having a
>> library with hundreds of user contributed templates / fully functional
>> synths that anyone can plug into their orchestras and patch into other
>> synths and DSPs, without the headaches of the current system.  That's the
>> world I want to live in.
>>
>> Best,
>> Jake
>>
>>     
>
>   

This is virtually identical to my latest proposal. My proposed connect
opcode does what your patchcord macro does, but it does not require a
score event to get it to work.

Regards,
Mike.

On 9/14/09, Oeyvind Brandtsegg  wrote:
> I do like the idea of doing this inside Csound, with no dependency on
> an external language. I also think that Michaels proposed strategy
> might provide us with tools for easier patching of signals in an
> orchestra, even for situations where we code in Csound without having
> in mind that we want to share the instruments. I also seems like this
> proposed strategy could be useful when we start thinking more about
> runtime dynamic instruments. It also seems like Jacob has given this a
> lot of thought, and have considered a number of requirements for this
> to work in practice. It would be of great value if these efforts could
> be merged into one strategy.
>
> I've attached a simple "patchcord csd", for what it's worth. It's
> probably way too simple, and you have certainly thought of this way of
> using macros already. ... and it's only related to dynamic signal
> patching using excisting Csound opcodes. But here it is anyway.
> If we had a way of recognizing the number of arguments to a macro, it
> would be relatively easy to expand this to allow arbitrary number of
> inputs and outputs for a "patch cord".
>
> Oeyvind
>
>
> 2009/9/12 Michael Gogins :
>> 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"
>
> 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"

The ftgenonce lookup happens only at i-rate. Most of time, there is
one i-rate invocation per instrument instance per hundreds to hundreds
of thousands of k-rate invocations. Furthermore, the lookup is by
binary search and should be quite efficient. Not all ftable arglists
are long.

I also think a new pmap opcode should be defined at global level, for
mapping score pfields to instrument pfields, again to simplify the
re-use of instruments across orchestras and across composers.

pmap Sinstrumentname p4=p5, p5=3, p6=[1 - p7^3],...

This would accept default values, formulas for rescaling, and so on.
There could be 1 pmap declaration per instrument actually used by a
score.

Regards,
Mike

On 9/14/09, Mark Van Peteghem  wrote:
> I like this example a lot, it makes it a lot easier to do things like
> reverb without putting it in an instrument. But as a programmer I wonder
> immediately if using these strings is efficient; looking up a string is
> slower than looking up a number; but maybe this is taken care of when
> compiling the orchestra and score.
>
> After reading Victors article in the latest CSound journal, I thought
> about writing the core of instruments in a UDO, so it is easier to use
> it with both MIDI parameters and volume+pitch, by having a simple
> instrument that transforms MIDI parameters into volume and pitch and
> calls the UDO with these. But you could do the same with the mechanism
> you propose here.
>
> Mark
>
> Jacob Joaquin wrote:
>> I built a prototype in python.  It's about as barebones and fugly as it
>> gets,
>> but it works.
>>
>> I want to briefly describe what this prototype does.  Instead of creating
>> instrs in the orchestra, I created classes.  Writing a class is nearly
>> identical to writing an instr.  A class by itself does nothing.  An instr
>> must be created from a class for it to be useful.  Multiple instrs can be
>> created from the same class, with each instr being assigned its own unique
>> instr number.  Classes support optional arguments, with the values of the
>> arguments being assigned when instrs are created.
>>
>> In the examples listed near the bottom of this post, I designed the
>> classes
>> so that the optional arguments are the names of chn input and output
>> busses.
>> This allowed me to patch instrs as I create them, instead of hardwiring
>> them
>> directly inside of instr blocks.
>>
>> The first example is fairly straight forward.  The Basic class, when
>> created, generates an enveloped sine wave, and is written to the chn buss
>> "basic_1".  The instance of MonoOut taps "basic_1" and sends it to the out
>> opcode.  The final class, Clear, is used to clear the chn buss "basic_1"
>> so
>> that feedback does not occur.  This won't be an issue once inlet/outlet
>> opcodes are released as part of a future version of Csound.
>>
>> Example 1 before being processed:
>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd
>>
>> Example 1 after being processed (Csound can render this):
>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd
>>
>>
>> The second example builds off the first, and demonstrates how multiple
>> instances of the same class can be built.  Two instances of Basic2 and
>> MonoVerb are created, with each having its own unique instr number and
>> unique chn buss input/output names.
>>
>> Example 2 before being processed:
>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd
>>
>> Example 2 after being processed (Csound can render this):
>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd
>>
>>
>> You can download all the files here, including the python file that
>> preprocesses the classes:
>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip
>>
>>
>> I'll keep working on this in my spare time.  I'm going to incorporate it
>> into my CSD python package, and put everything up at sourceforge or google
>> code sometime in the next couple of weeks.  I'll keep everyone posted.
>>
>> Best,
>> Jake
>>
>>
>>
>> Jacob Joaquin wrote:
>>
>>> Reusing a Csound instrument in a new score typically involves copying and
>>> pasting the instrument into a new orchestra.  Once pasted, the user, more
>>> often than not, must make modifications to the instrument in order for it
>>> to work in its new environment.  Sometimes it is only a matter of
>>> changing
>>> the instrument number.  Other times, f-tables have to be ported and
>>> renumbered as well.  If there are software busses involve, such as zak,
>>> then modifications suddenly become a minor rewrite of the instrument.
>>>
>>> No one enjoys this.  Well, statistically speaking, I'm sure there is a
>>> handful of people that do.  Though as a general rule, this is tedious
>>> work
>>> that most Csounders would rather do without.
>>>
>>> I propose that we develop an instrument templating system for handling,
>>> importing and reusing instruments.
>>>
>>> In a nutshell, an instrument template is basically a Csound instrument,
>>> minus an assigned instrument number, plus it can support additional
>>> variables the can be designated when constructed. Here is an example of
>>> what a Csound instrument template might look like:
>>>
>>>     template Sinewave440
>>>         a1 oscils 1, 440, 1
>>>         out a1
>>>     end_template
>>>
>>> In this very basic example, the code in the body is 100% Csound.  This is
>>> important because templates should look familiar to Csounders.  Templates
>>> would exist in an orchestra, or in an external file.  In order to use
>>> this
>>> template, an instrument must be created from it.  The code to do this
>>> might look like this:
>>>
>>>     create_instr 1 Sinewave440
>>>
>>> Or if the template exists in external file:
>>>
>>>     import_template Sinewave440 from "./foo.orc"
>>>     create_instr 1 Sinewave440
>>>
>>> The instrument as it is only works when nchnls is set to one. Since
>>> portability is a goal, I will modify this template to make it more of a
>>> general purpose template.  Instead of sending a1 to the dac using out, I
>>> will instead send it to an audio buss using the upcoming outleta opcode.
>>>
>>>     template Sinewave262 #output
>>>         a1 oscils 1, 262, 1
>>>         outleta a1, #output
>>>     end_template
>>>
>>> Here, I introduced template arguments.  The example uses one argument,
>>> #output.  What ever text is supplied as the first parameter will replace
>>> #output in the body of the template, much like a macro.
>>>
>>>     create_instr 1 Sinewave262 "audio_out"
>>>
>>> After the preprocessor, the following Csound code is produced:
>>>
>>>     instr 1
>>>         a1 oscils 1, 262, 1
>>>         outleta a1, "audio_out"
>>>     endin
>>>
>>> To hear the audio, we still need to create an instrument that receives
>>> the
>>> audio and sends it to the dac or audio file.
>>>
>>>     template StereoOut #left_input #right_input
>>>         a1 inleta #left_input
>>>         a2 inleta #right_input
>>>         output a1, a2
>>>     end_template
>>>
>>>     create_instr 1 Sinewave262 "audio_out"
>>>     create_instr 2 StereoOut "audio_out" "audio_out"
>>>
>>> After the preprocessor, the previous code would produce the following
>>> orchestra code:
>>>
>>>     instr 1
>>>         a1 oscils 1, 262, 1
>>>         outleta a1, "audio_out"
>>>     endin
>>>
>>>     instr 2
>>>         a1 inleta "audio_out"
>>>         a2 inleta "audio_out"
>>>         output a1, a2
>>>     endin
>>>
>>> The greater implication is that instruments/templates could be used in a
>>> much more modular fashion.  Since numbers and buss names aren't assigned
>>> until an instr is created, Csounders would be able to patch together
>>> complex systems far easier and faster than is currently possible.
>>>
>>> Here is a longer example that makes use of this theoretical patching
>>> system:
>>>
>>>     template MySynth #output #fn
>>>         iamp = p4
>>>         ifreq = p5
>>>         ifn = #fn
>>>
>>>         a1 oscil iamp, ifreq, ifn
>>>         outlet a1, #output
>>>     end_template
>>>
>>>     template TheVerb #input #output #reverb_time
>>>         itime = #reverb_time
>>>
>>>         a1 inleta #input
>>>         a1 reverb a1, itime
>>>
>>>         outlet a1, #output
>>>     end_template
>>>
>>>     template StereoOut #left #right
>>>         a1 inleta #left
>>>         a2 inleta #right
>>>         output a1, a2
>>>     end_template
>>>
>>>     gir ftgen 33, 0, 8192, 10, 1
>>>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>>>
>>>     create_instr 1 MySynth "synth_out_1" 33
>>>     create_instr 2 MySynth "synth_out_2" 34
>>>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>>>     create_instr 4 StereoOut "synth_out_1" "verb_out"
>>>
>>> The score:
>>>
>>>     i 1 0 4 0.5 440  ; sine, panned hard left
>>>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>>>     i 3 0 -1
>>>     i 4 0 -1
>>>
>>> This is only the beginning of an idea, and much more thought is required.
>>>
>>> Though I do believe that a system like this or similar would make Csound
>>> much more pleasant to work with, by leaps and bounds.  Imagine having a
>>> library with hundreds of user contributed templates / fully functional
>>> synths that anyone can plug into their orchestras and patch into other
>>> synths and DSPs, without the headaches of the current system.  That's the
>>> world I want to live in.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>
>>
>
> --
>   Mark
>   _________________________________________
>   When you get lemons, you make lemonade.
>   When you get hardware, you make software.
>
>
>
> 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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel

I agree that Csound itself needs functionality extensions to make this work. 
Though raw power alone isn't enough.  As we move forward, we have to
consider the interface, syntax, aesthetics, how users interact with it, how
quickly and easy someone can digest someone elses codes, import instruments
from others, etc.  If the final system does take not these things into
consideration, the advantages of this potential new system will be
overshadowed by the disadvantages of complexity.  A well designed system has
form and function.

I'm approaching the problem from a design perspective.  Though I'm first
trying to figure out what the goals of this new system should be by
soliciting the community.  By providing mock up code, and mock up examples,
I've done, it gives a preview of what the system could be, and helps figure
out many of the pitfalls and traps, before we implement it.

As we all know, once something becomes part of Csound, it becomes part of
Csound forever.  We *have* to take our time with this.  If we rush it, we'll
get it wrong, and then we're just left with another half-thought out system
implemented in Csound that has no hope of being fixed.  Let's take our time,
build several versions, identify the problems, figure out our goals, and
then pull everything together.

I disagree that my proposed solution as it stands isn't assembly-like. 
Class design will still be virtually identical to instrument design. 
Classes would just make instrument sharing a no-brainer.  Instrument sharing
is critical to community growing.

Best,
Jake



Stéphane Rollandin wrote:
> 
>> I guess what I'm proposing is that we define a specification, implement
>> this
>> specification in an external engine such as a Python module, until it is
>> refined enough to become part of Csound.  Not something to take lightly
>> for
>> sure, and I expect this will take much trial and error if we are to get
>> it
>> right.
> 
> this is a cost-less approach, so I see no problem with it.
> 
> now, if no consensus can be found, nothing prevents you from developping 
> your Python scripts in any direction you like: you will not be bothered 
> by endless discussion to convince others, instead just provide your 
> independent set of tools for anyone to use. this is what I do with 
> Emacs, and as I said earlier it feels to me like the right approach: 
> keep the actual Csound syntax as an assembly-like language, and design 
> high-level languages/metaphors above it.
> 
> in that context, what we should strive for in Csound itself is true 
> functionality extension, like what Mike Gogins is doing right now with 
> his new opcodes. he just adds raw power to the core language, while we 
> add flexibility and high-level modularity via external preprocessing 
> languages.
> 
> does this make sense ?
> 
> 
> Stef
> 
> 
> 
> 
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> 

-- 
View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25435770.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"

Your use cases and example code have been very helpful to me in
clarifying the design requirements for such a system. Mainly, I am
trying to come up with opcodes to support your use cases.

I completely agree the system needs to be as simple as possible and as
intuitive to use as possible.

Re-usable instruments have to plug into orchestras, this is what the
suggested inlet, outlet, and connect opcodes are for. It should NOT be
necessary to modify any re-usable instrument code to do this. I
believe I see how to implement opcodes to support this.

Re-usable instruments should NOT depend on f-statements in the score,
this is what the ftgenonce opcode is for. I definitely see how to
implement an opcode for this.

Re-usable instruments have to plug into a composer's score, this is
what the suggested pmap opcode is for. I feel this part of the
specification may need more work.

PLEASE let me know if these ideas are sufficient to implement what you
need. Also, any suggestions for better names, more examples, more use
cases would be most appreciated.

The weak points that I see in my suggestions so far are (1) the need
to define instruments in the correct order and (2) the need to use
pmap to map scores to re-usable instrument pfields.

I do not see any solution for the first point aside from changing
Csound orchestra parser internals which I do not wish to do. Therefore
I am willing to live with this for the time being. This, obviously, is
NOT an issue for a preprocessor.

The second point would be obviated if we could agree on a standard
pfield format, but I think this would be very difficult.

Perhaps we could agree on a "suggested pfield format" but permit the
use of pmap for extended pfield setups.

Regards,
Mike

On 9/14/09, Jacob Joaquin  wrote:
>
> I agree that Csound itself needs functionality extensions to make this work.
> Though raw power alone isn't enough.  As we move forward, we have to
> consider the interface, syntax, aesthetics, how users interact with it, how
> quickly and easy someone can digest someone elses codes, import instruments
> from others, etc.  If the final system does take not these things into
> consideration, the advantages of this potential new system will be
> overshadowed by the disadvantages of complexity.  A well designed system has
> form and function.
>
> I'm approaching the problem from a design perspective.  Though I'm first
> trying to figure out what the goals of this new system should be by
> soliciting the community.  By providing mock up code, and mock up examples,
> I've done, it gives a preview of what the system could be, and helps figure
> out many of the pitfalls and traps, before we implement it.
>
> As we all know, once something becomes part of Csound, it becomes part of
> Csound forever.  We *have* to take our time with this.  If we rush it, we'll
> get it wrong, and then we're just left with another half-thought out system
> implemented in Csound that has no hope of being fixed.  Let's take our time,
> build several versions, identify the problems, figure out our goals, and
> then pull everything together.
>
> I disagree that my proposed solution as it stands isn't assembly-like.
> Class design will still be virtually identical to instrument design.
> Classes would just make instrument sharing a no-brainer.  Instrument sharing
> is critical to community growing.
>
> Best,
> Jake
>
>
>
> Stéphane Rollandin wrote:
>>
>>> I guess what I'm proposing is that we define a specification, implement
>>> this
>>> specification in an external engine such as a Python module, until it is
>>> refined enough to become part of Csound.  Not something to take lightly
>>> for
>>> sure, and I expect this will take much trial and error if we are to get
>>> it
>>> right.
>>
>> this is a cost-less approach, so I see no problem with it.
>>
>> now, if no consensus can be found, nothing prevents you from developping
>> your Python scripts in any direction you like: you will not be bothered
>> by endless discussion to convince others, instead just provide your
>> independent set of tools for anyone to use. this is what I do with
>> Emacs, and as I said earlier it feels to me like the right approach:
>> keep the actual Csound syntax as an assembly-like language, and design
>> high-level languages/metaphors above it.
>>
>> in that context, what we should strive for in Csound itself is true
>> functionality extension, like what Mike Gogins is doing right now with
>> his new opcodes. he just adds raw power to the core language, while we
>> add flexibility and high-level modularity via external preprocessing
>> languages.
>>
>> does this make sense ?
>>
>>
>> Stef
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25435770.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"

Michael Gogins wrote:
> The ftgenonce lookup happens only at i-rate. Most of time, there is
> one i-rate invocation per instrument instance per hundreds to hundreds
> of thousands of k-rate invocations. Furthermore, the lookup is by
> binary search and should be quite efficient. Not all ftable arglists
> are long.
>   

The example below that I was talking about doesn't use ftgenonce, it 
uses chnset and chnget instead.

> I also think a new pmap opcode should be defined at global level, for
> mapping score pfields to instrument pfields, again to simplify the
> re-use of instruments across orchestras and across composers.
>
> pmap Sinstrumentname p4=p5, p5=3, p6=[1 - p7^3],...
>
> This would accept default values, formulas for rescaling, and so on.
> There could be 1 pmap declaration per instrument actually used by a
> score.
>   

This looks very useful. Especially if it can use the functions that are 
available in CSound, like cpsmidinn.

Mark

> On 9/14/09, Mark Van Peteghem  wrote:
>   
>> I like this example a lot, it makes it a lot easier to do things like
>> reverb without putting it in an instrument. But as a programmer I wonder
>> immediately if using these strings is efficient; looking up a string is
>> slower than looking up a number; but maybe this is taken care of when
>> compiling the orchestra and score.
>>
>> After reading Victors article in the latest CSound journal, I thought
>> about writing the core of instruments in a UDO, so it is easier to use
>> it with both MIDI parameters and volume+pitch, by having a simple
>> instrument that transforms MIDI parameters into volume and pitch and
>> calls the UDO with these. But you could do the same with the mechanism
>> you propose here.
>>
>> Mark
>>
>> Jacob Joaquin wrote:
>>     
>>> I built a prototype in python.  It's about as barebones and fugly as it
>>> gets,
>>> but it works.
>>>
>>> I want to briefly describe what this prototype does.  Instead of creating
>>> instrs in the orchestra, I created classes.  Writing a class is nearly
>>> identical to writing an instr.  A class by itself does nothing.  An instr
>>> must be created from a class for it to be useful.  Multiple instrs can be
>>> created from the same class, with each instr being assigned its own unique
>>> instr number.  Classes support optional arguments, with the values of the
>>> arguments being assigned when instrs are created.
>>>
>>> In the examples listed near the bottom of this post, I designed the
>>> classes
>>> so that the optional arguments are the names of chn input and output
>>> busses.
>>> This allowed me to patch instrs as I create them, instead of hardwiring
>>> them
>>> directly inside of instr blocks.
>>>
>>> The first example is fairly straight forward.  The Basic class, when
>>> created, generates an enveloped sine wave, and is written to the chn buss
>>> "basic_1".  The instance of MonoOut taps "basic_1" and sends it to the out
>>> opcode.  The final class, Clear, is used to clear the chn buss "basic_1"
>>> so
>>> that feedback does not occur.  This won't be an issue once inlet/outlet
>>> opcodes are released as part of a future version of Csound.
>>>
>>> Example 1 before being processed:
>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd
>>>
>>> Example 1 after being processed (Csound can render this):
>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd
>>>
>>>
>>> The second example builds off the first, and demonstrates how multiple
>>> instances of the same class can be built.  Two instances of Basic2 and
>>> MonoVerb are created, with each having its own unique instr number and
>>> unique chn buss input/output names.
>>>
>>> Example 2 before being processed:
>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd
>>>
>>> Example 2 after being processed (Csound can render this):
>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd
>>>
>>>
>>> You can download all the files here, including the python file that
>>> preprocesses the classes:
>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip
>>>
>>>
>>> I'll keep working on this in my spare time.  I'm going to incorporate it
>>> into my CSD python package, and put everything up at sourceforge or google
>>> code sometime in the next couple of weeks.  I'll keep everyone posted.
>>>
>>> Best,
>>> Jake
>>>
>>>
>>>
>>> Jacob Joaquin wrote:
>>>
>>>       
>>>> Reusing a Csound instrument in a new score typically involves copying and
>>>> pasting the instrument into a new orchestra.  Once pasted, the user, more
>>>> often than not, must make modifications to the instrument in order for it
>>>> to work in its new environment.  Sometimes it is only a matter of
>>>> changing
>>>> the instrument number.  Other times, f-tables have to be ported and
>>>> renumbered as well.  If there are software busses involve, such as zak,
>>>> then modifications suddenly become a minor rewrite of the instrument.
>>>>
>>>> No one enjoys this.  Well, statistically speaking, I'm sure there is a
>>>> handful of people that do.  Though as a general rule, this is tedious
>>>> work
>>>> that most Csounders would rather do without.
>>>>
>>>> I propose that we develop an instrument templating system for handling,
>>>> importing and reusing instruments.
>>>>
>>>> In a nutshell, an instrument template is basically a Csound instrument,
>>>> minus an assigned instrument number, plus it can support additional
>>>> variables the can be designated when constructed. Here is an example of
>>>> what a Csound instrument template might look like:
>>>>
>>>>     template Sinewave440
>>>>         a1 oscils 1, 440, 1
>>>>         out a1
>>>>     end_template
>>>>
>>>> In this very basic example, the code in the body is 100% Csound.  This is
>>>> important because templates should look familiar to Csounders.  Templates
>>>> would exist in an orchestra, or in an external file.  In order to use
>>>> this
>>>> template, an instrument must be created from it.  The code to do this
>>>> might look like this:
>>>>
>>>>     create_instr 1 Sinewave440
>>>>
>>>> Or if the template exists in external file:
>>>>
>>>>     import_template Sinewave440 from "./foo.orc"
>>>>     create_instr 1 Sinewave440
>>>>
>>>> The instrument as it is only works when nchnls is set to one. Since
>>>> portability is a goal, I will modify this template to make it more of a
>>>> general purpose template.  Instead of sending a1 to the dac using out, I
>>>> will instead send it to an audio buss using the upcoming outleta opcode.
>>>>
>>>>     template Sinewave262 #output
>>>>         a1 oscils 1, 262, 1
>>>>         outleta a1, #output
>>>>     end_template
>>>>
>>>> Here, I introduced template arguments.  The example uses one argument,
>>>> #output.  What ever text is supplied as the first parameter will replace
>>>> #output in the body of the template, much like a macro.
>>>>
>>>>     create_instr 1 Sinewave262 "audio_out"
>>>>
>>>> After the preprocessor, the following Csound code is produced:
>>>>
>>>>     instr 1
>>>>         a1 oscils 1, 262, 1
>>>>         outleta a1, "audio_out"
>>>>     endin
>>>>
>>>> To hear the audio, we still need to create an instrument that receives
>>>> the
>>>> audio and sends it to the dac or audio file.
>>>>
>>>>     template StereoOut #left_input #right_input
>>>>         a1 inleta #left_input
>>>>         a2 inleta #right_input
>>>>         output a1, a2
>>>>     end_template
>>>>
>>>>     create_instr 1 Sinewave262 "audio_out"
>>>>     create_instr 2 StereoOut "audio_out" "audio_out"
>>>>
>>>> After the preprocessor, the previous code would produce the following
>>>> orchestra code:
>>>>
>>>>     instr 1
>>>>         a1 oscils 1, 262, 1
>>>>         outleta a1, "audio_out"
>>>>     endin
>>>>
>>>>     instr 2
>>>>         a1 inleta "audio_out"
>>>>         a2 inleta "audio_out"
>>>>         output a1, a2
>>>>     endin
>>>>
>>>> The greater implication is that instruments/templates could be used in a
>>>> much more modular fashion.  Since numbers and buss names aren't assigned
>>>> until an instr is created, Csounders would be able to patch together
>>>> complex systems far easier and faster than is currently possible.
>>>>
>>>> Here is a longer example that makes use of this theoretical patching
>>>> system:
>>>>
>>>>     template MySynth #output #fn
>>>>         iamp = p4
>>>>         ifreq = p5
>>>>         ifn = #fn
>>>>
>>>>         a1 oscil iamp, ifreq, ifn
>>>>         outlet a1, #output
>>>>     end_template
>>>>
>>>>     template TheVerb #input #output #reverb_time
>>>>         itime = #reverb_time
>>>>
>>>>         a1 inleta #input
>>>>         a1 reverb a1, itime
>>>>
>>>>         outlet a1, #output
>>>>     end_template
>>>>
>>>>     template StereoOut #left #right
>>>>         a1 inleta #left
>>>>         a2 inleta #right
>>>>         output a1, a2
>>>>     end_template
>>>>
>>>>     gir ftgen 33, 0, 8192, 10, 1
>>>>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>>>>
>>>>     create_instr 1 MySynth "synth_out_1" 33
>>>>     create_instr 2 MySynth "synth_out_2" 34
>>>>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>>>>     create_instr 4 StereoOut "synth_out_1" "verb_out"
>>>>
>>>> The score:
>>>>
>>>>     i 1 0 4 0.5 440  ; sine, panned hard left
>>>>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>>>>     i 3 0 -1
>>>>     i 4 0 -1
>>>>
>>>> This is only the beginning of an idea, and much more thought is required.
>>>>
>>>> Though I do believe that a system like this or similar would make Csound
>>>> much more pleasant to work with, by leaps and bounds.  Imagine having a
>>>> library with hundreds of user contributed templates / fully functional
>>>> synths that anyone can plug into their orchestras and patch into other
>>>> synths and DSPs, without the headaches of the current system.  That's the
>>>> world I want to live in.
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>>
>>>>         
>>>       
>> --
>>   Mark
>>   _________________________________________
>>   When you get lemons, you make lemonade.
>>   When you get hardware, you make software.
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>     
>
>
>   

> I agree that Csound itself needs functionality extensions to make this work. 
> Though raw power alone isn't enough.  As we move forward, we have to
> consider the interface, syntax, aesthetics, how users interact with it, how
> quickly and easy someone can digest someone elses codes, import instruments
> from others, etc.  If the final system does take not these things into
> consideration, the advantages of this potential new system will be
> overshadowed by the disadvantages of complexity.  A well designed system has
> form and function.

sure, but what is wrong with having all of this implemented as a front-end ?


> I'm approaching the problem from a design perspective.  Though I'm first
> trying to figure out what the goals of this new system should be by
> soliciting the community.  By providing mock up code, and mock up examples,
> I've done, it gives a preview of what the system could be, and helps figure
> out many of the pitfalls and traps, before we implement it.
> 
> As we all know, once something becomes part of Csound, it becomes part of
> Csound forever.  We *have* to take our time with this.  If we rush it, we'll
> get it wrong, and then we're just left with another half-thought out system
> implemented in Csound that has no hope of being fixed.  Let's take our time,
> build several versions, identify the problems, figure out our goals, and
> then pull everything together.

this is precisely my mindset.


> I disagree that my proposed solution as it stands isn't assembly-like. 
> Class design will still be virtually identical to instrument design. 
> Classes would just make instrument sharing a no-brainer.  Instrument sharing
> is critical to community growing.

the point I have been trying to make is that your current proposal is 
just a beginning, even if you consider it sufficient at this time. so, 
yes, currently as you describe it, it is not a big departure from Csound 
syntax and, as I already stated, I have nothing against it.

simply, believing that this proposal is a complete solution to the 
problems you address (instrument sharing) is an error IMO. for example,
let's say I discover your great class

     class Foo #outlet
         a1 oscils 1, 440, 1
         outleta "#outlet", a1
     endclass

and I want to use it. but 440 is not my cup of tea, for some reason I 
base everything on 451,12. plus I don't want to use table 1, but table 
23. I'm stuck, the class template is of no use at all. so maybe a common 
practice will be for instrument developers to explicit all meaningful 
parameters, so the community will provide

     class Foo #outlet #freq #n1 #n2
         a1 oscils #n1, #freq, #n2
         outleta "#outlet", a1
     endclass

but then, someone will say:


ok guys we have a very nice instruments with many parameters, but really 
I only work with table 1 and frequency 440, so let me introduce a new 
idea, let's define a "class ... curry ..." construct so that we can 
create a specialized instrument out of a generic one, like this:

    class SpecializedFoo curry Foo #outlet 440 1 1

which will make it equivalent to

     class SpecializedFoo #outlet
         a1 oscils 1, 440, 1
         outleta "#outlet", a1
     endclass

wouldn't this be great ?


and yes it would be great.

etc.

see what I mean ? if we want to address seriously (as opposed to 
hackishly) the problem of instrument sharing, we will certainly not be 
satisfied with your proposal alone. I'm convinced that high-level 
concerns can only be solved by high-level concepts, that is a 
full-fledged OOP/functional/whatever language with Csound is not; and 
incrementally creating that language up from Csound syntax is going to 
be ugly. the correct way to do so is downward, from scripting language 
down to Csound assembly, else we have to rewrite Csound from scratch 
which I assume nobody wants to do.


regards,

Stef




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

The argument about lookup applies not only to ftgenonce, but also to
inlets and outlets. The name lookup only happens during the outlet
opcode's init time, when it gets a pointer to its vector of inlets.
After that, at k-rate or a-rate, it just iterates over its vector of
inlets.

Regards,
mike

On 9/14/09, Mark Van Peteghem  wrote:
> Michael Gogins wrote:
>> The ftgenonce lookup happens only at i-rate. Most of time, there is
>> one i-rate invocation per instrument instance per hundreds to hundreds
>> of thousands of k-rate invocations. Furthermore, the lookup is by
>> binary search and should be quite efficient. Not all ftable arglists
>> are long.
>>
>
> The example below that I was talking about doesn't use ftgenonce, it
> uses chnset and chnget instead.
>
>> I also think a new pmap opcode should be defined at global level, for
>> mapping score pfields to instrument pfields, again to simplify the
>> re-use of instruments across orchestras and across composers.
>>
>> pmap Sinstrumentname p4=p5, p5=3, p6=[1 - p7^3],...
>>
>> This would accept default values, formulas for rescaling, and so on.
>> There could be 1 pmap declaration per instrument actually used by a
>> score.
>>
>
> This looks very useful. Especially if it can use the functions that are
> available in CSound, like cpsmidinn.
>
> Mark
>
>> On 9/14/09, Mark Van Peteghem  wrote:
>>
>>> I like this example a lot, it makes it a lot easier to do things like
>>> reverb without putting it in an instrument. But as a programmer I wonder
>>> immediately if using these strings is efficient; looking up a string is
>>> slower than looking up a number; but maybe this is taken care of when
>>> compiling the orchestra and score.
>>>
>>> After reading Victors article in the latest CSound journal, I thought
>>> about writing the core of instruments in a UDO, so it is easier to use
>>> it with both MIDI parameters and volume+pitch, by having a simple
>>> instrument that transforms MIDI parameters into volume and pitch and
>>> calls the UDO with these. But you could do the same with the mechanism
>>> you propose here.
>>>
>>> Mark
>>>
>>> Jacob Joaquin wrote:
>>>
>>>> I built a prototype in python.  It's about as barebones and fugly as it
>>>> gets,
>>>> but it works.
>>>>
>>>> I want to briefly describe what this prototype does.  Instead of
>>>> creating
>>>> instrs in the orchestra, I created classes.  Writing a class is nearly
>>>> identical to writing an instr.  A class by itself does nothing.  An
>>>> instr
>>>> must be created from a class for it to be useful.  Multiple instrs can
>>>> be
>>>> created from the same class, with each instr being assigned its own
>>>> unique
>>>> instr number.  Classes support optional arguments, with the values of
>>>> the
>>>> arguments being assigned when instrs are created.
>>>>
>>>> In the examples listed near the bottom of this post, I designed the
>>>> classes
>>>> so that the optional arguments are the names of chn input and output
>>>> busses.
>>>> This allowed me to patch instrs as I create them, instead of hardwiring
>>>> them
>>>> directly inside of instr blocks.
>>>>
>>>> The first example is fairly straight forward.  The Basic class, when
>>>> created, generates an enveloped sine wave, and is written to the chn
>>>> buss
>>>> "basic_1".  The instance of MonoOut taps "basic_1" and sends it to the
>>>> out
>>>> opcode.  The final class, Clear, is used to clear the chn buss "basic_1"
>>>> so
>>>> that feedback does not occur.  This won't be an issue once inlet/outlet
>>>> opcodes are released as part of a future version of Csound.
>>>>
>>>> Example 1 before being processed:
>>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic.csd
>>>>
>>>> Example 1 after being processed (Csound can render this):
>>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/basic_realized.csd
>>>>
>>>>
>>>> The second example builds off the first, and demonstrates how multiple
>>>> instances of the same class can be built.  Two instances of Basic2 and
>>>> MonoVerb are created, with each having its own unique instr number and
>>>> unique chn buss input/output names.
>>>>
>>>> Example 2 before being processed:
>>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_example.csd
>>>>
>>>> Example 2 after being processed (Csound can render this):
>>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype/fx_realized.csd
>>>>
>>>>
>>>> You can download all the files here, including the python file that
>>>> preprocesses the classes:
>>>> http://www.thumbuki.com/csound/files/mailinglist/CsoundClassEarlyPrototype.zip
>>>>
>>>>
>>>> I'll keep working on this in my spare time.  I'm going to incorporate it
>>>> into my CSD python package, and put everything up at sourceforge or
>>>> google
>>>> code sometime in the next couple of weeks.  I'll keep everyone posted.
>>>>
>>>> Best,
>>>> Jake
>>>>
>>>>
>>>>
>>>> Jacob Joaquin wrote:
>>>>
>>>>
>>>>> Reusing a Csound instrument in a new score typically involves copying
>>>>> and
>>>>> pasting the instrument into a new orchestra.  Once pasted, the user,
>>>>> more
>>>>> often than not, must make modifications to the instrument in order for
>>>>> it
>>>>> to work in its new environment.  Sometimes it is only a matter of
>>>>> changing
>>>>> the instrument number.  Other times, f-tables have to be ported and
>>>>> renumbered as well.  If there are software busses involve, such as zak,
>>>>> then modifications suddenly become a minor rewrite of the instrument.
>>>>>
>>>>> No one enjoys this.  Well, statistically speaking, I'm sure there is a
>>>>> handful of people that do.  Though as a general rule, this is tedious
>>>>> work
>>>>> that most Csounders would rather do without.
>>>>>
>>>>> I propose that we develop an instrument templating system for handling,
>>>>> importing and reusing instruments.
>>>>>
>>>>> In a nutshell, an instrument template is basically a Csound instrument,
>>>>> minus an assigned instrument number, plus it can support additional
>>>>> variables the can be designated when constructed. Here is an example of
>>>>> what a Csound instrument template might look like:
>>>>>
>>>>>     template Sinewave440
>>>>>         a1 oscils 1, 440, 1
>>>>>         out a1
>>>>>     end_template
>>>>>
>>>>> In this very basic example, the code in the body is 100% Csound.  This
>>>>> is
>>>>> important because templates should look familiar to Csounders.
>>>>> Templates
>>>>> would exist in an orchestra, or in an external file.  In order to use
>>>>> this
>>>>> template, an instrument must be created from it.  The code to do this
>>>>> might look like this:
>>>>>
>>>>>     create_instr 1 Sinewave440
>>>>>
>>>>> Or if the template exists in external file:
>>>>>
>>>>>     import_template Sinewave440 from "./foo.orc"
>>>>>     create_instr 1 Sinewave440
>>>>>
>>>>> The instrument as it is only works when nchnls is set to one. Since
>>>>> portability is a goal, I will modify this template to make it more of a
>>>>> general purpose template.  Instead of sending a1 to the dac using out,
>>>>> I
>>>>> will instead send it to an audio buss using the upcoming outleta
>>>>> opcode.
>>>>>
>>>>>     template Sinewave262 #output
>>>>>         a1 oscils 1, 262, 1
>>>>>         outleta a1, #output
>>>>>     end_template
>>>>>
>>>>> Here, I introduced template arguments.  The example uses one argument,
>>>>> #output.  What ever text is supplied as the first parameter will
>>>>> replace
>>>>> #output in the body of the template, much like a macro.
>>>>>
>>>>>     create_instr 1 Sinewave262 "audio_out"
>>>>>
>>>>> After the preprocessor, the following Csound code is produced:
>>>>>
>>>>>     instr 1
>>>>>         a1 oscils 1, 262, 1
>>>>>         outleta a1, "audio_out"
>>>>>     endin
>>>>>
>>>>> To hear the audio, we still need to create an instrument that receives
>>>>> the
>>>>> audio and sends it to the dac or audio file.
>>>>>
>>>>>     template StereoOut #left_input #right_input
>>>>>         a1 inleta #left_input
>>>>>         a2 inleta #right_input
>>>>>         output a1, a2
>>>>>     end_template
>>>>>
>>>>>     create_instr 1 Sinewave262 "audio_out"
>>>>>     create_instr 2 StereoOut "audio_out" "audio_out"
>>>>>
>>>>> After the preprocessor, the previous code would produce the following
>>>>> orchestra code:
>>>>>
>>>>>     instr 1
>>>>>         a1 oscils 1, 262, 1
>>>>>         outleta a1, "audio_out"
>>>>>     endin
>>>>>
>>>>>     instr 2
>>>>>         a1 inleta "audio_out"
>>>>>         a2 inleta "audio_out"
>>>>>         output a1, a2
>>>>>     endin
>>>>>
>>>>> The greater implication is that instruments/templates could be used in
>>>>> a
>>>>> much more modular fashion.  Since numbers and buss names aren't
>>>>> assigned
>>>>> until an instr is created, Csounders would be able to patch together
>>>>> complex systems far easier and faster than is currently possible.
>>>>>
>>>>> Here is a longer example that makes use of this theoretical patching
>>>>> system:
>>>>>
>>>>>     template MySynth #output #fn
>>>>>         iamp = p4
>>>>>         ifreq = p5
>>>>>         ifn = #fn
>>>>>
>>>>>         a1 oscil iamp, ifreq, ifn
>>>>>         outlet a1, #output
>>>>>     end_template
>>>>>
>>>>>     template TheVerb #input #output #reverb_time
>>>>>         itime = #reverb_time
>>>>>
>>>>>         a1 inleta #input
>>>>>         a1 reverb a1, itime
>>>>>
>>>>>         outlet a1, #output
>>>>>     end_template
>>>>>
>>>>>     template StereoOut #left #right
>>>>>         a1 inleta #left
>>>>>         a2 inleta #right
>>>>>         output a1, a2
>>>>>     end_template
>>>>>
>>>>>     gir ftgen 33, 0, 8192, 10, 1
>>>>>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>>>>>
>>>>>     create_instr 1 MySynth "synth_out_1" 33
>>>>>     create_instr 2 MySynth "synth_out_2" 34
>>>>>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>>>>>     create_instr 4 StereoOut "synth_out_1" "verb_out"
>>>>>
>>>>> The score:
>>>>>
>>>>>     i 1 0 4 0.5 440  ; sine, panned hard left
>>>>>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>>>>>     i 3 0 -1
>>>>>     i 4 0 -1
>>>>>
>>>>> This is only the beginning of an idea, and much more thought is
>>>>> required.
>>>>>
>>>>> Though I do believe that a system like this or similar would make
>>>>> Csound
>>>>> much more pleasant to work with, by leaps and bounds.  Imagine having a
>>>>> library with hundreds of user contributed templates / fully functional
>>>>> synths that anyone can plug into their orchestras and patch into other
>>>>> synths and DSPs, without the headaches of the current system.  That's
>>>>> the
>>>>> world I want to live in.
>>>>>
>>>>> Best,
>>>>> Jake
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>>   Mark
>>>   _________________________________________
>>>   When you get lemons, you make lemonade.
>>>   When you get hardware, you make software.
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>>
>
> --
>   Mark
>   _________________________________________
>   When you get lemons, you make lemonade.
>   When you get hardware, you make software.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Stéphane Rollandin wrote:
> 
> sure, but what is wrong with having all of this implemented as a front-end
> ?
> 

There's nothing wrong.  It may become apparent that the front-end approach
is the right one later down the road.  Though we shouldn't dismiss either
implementation at this point.


Stéphane Rollandin wrote:
> 
> the point I have been trying to make is that your current proposal is 
> just a beginning, even if you consider it sufficient at this time.
> 

I actually don't find the current proposal sufficient at all.  There are
issues which I've thought of that I haven't posted to the list yet.  For
example, how to handle compound instruments.  By compound instrument, I mean
a series of instruments that work together, but operate as if it were single
instrument in the score.  This is typically accomplished using busses and
instrument scheduling.  Here's an example of what I mean:

http://www.thumbuki.com/csound/files/thumbuki20061227.csd




Stéphane Rollandin wrote:
> 
> simply, believing that this proposal is a complete solution to the 
> problems you address (instrument sharing) is an error IMO. for example,
> let's say I discover your great class
> 
>      class Foo #outlet
>          a1 oscils 1, 440, 1
>          outleta "#outlet", a1
>      endclass
> 
> and I want to use it. but 440 is not my cup of tea, for some reason I 
> base everything on 451,12. plus I don't want to use table 1, but table 
> 23. I'm stuck, the class template is of no use at all. so maybe a common 
> practice will be for instrument developers to explicit all meaningful 
> parameters, so the community will provide
> 

I'm not suggesting that we should do away modifying other peoples synths,
whether they exist as instruments or classes or whatever.  Nor would I ever
suggest such a thing, because that is and will always be an important part
of Csound and the creative process.  I'm the kind of guy who likes to tinker
with things, so I imagine I would create new classes by modifying existing
classes.  I get it.

Though assume for a moment that classes are common, whether as a front-end
or part of Csound.  Classes would allow new Csounders to easily create
instrument graphs and write scores, without even knowing how to build an
instrument.  They could skip the instrument creation process, or instrument
modification process, and start writing music almost immediately.  This
wouldn't be all that different than how some people work in Reaktor, as many
just patch together the pre-built synths rather than design their own.

Best,
Jake






-- 
View this message in context: http://www.nabble.com/True-Plug-and-Play-Instruments-with-Templates-tp25392091p25438352.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"

First, I do want to say that I think we are far more in agreement than
disagreement.  For example, ftgenonce would be amazing on it's own.  The
idea of declaring certain instruments as always on, instead of having to
write 'i 1 0 -1' in the score, would also be a big deal.  pmap shows
promise, though I'll have to grok it a bit before I can comment on it.

I'll have some spare time today in which I plan on upgrading the py script. 
After that, I'll be better prepared to discuss some of our different ideas
on a deeper level.

Best,
Jake


Michael Gogins-2 wrote:
> 
> Your use cases and example code have been very helpful to me in
> clarifying the design requirements for such a system. Mainly, I am
> trying to come up with opcodes to support your use cases.
> 
> I completely agree the system needs to be as simple as possible and as
> intuitive to use as possible.
> 
> Re-usable instruments have to plug into orchestras, this is what the
> suggested inlet, outlet, and connect opcodes are for. It should NOT be
> necessary to modify any re-usable instrument code to do this. I
> believe I see how to implement opcodes to support this.
> 
> Re-usable instruments should NOT depend on f-statements in the score,
> this is what the ftgenonce opcode is for. I definitely see how to
> implement an opcode for this.
> 
> Re-usable instruments have to plug into a composer's score, this is
> what the suggested pmap opcode is for. I feel this part of the
> specification may need more work.
> 
> PLEASE let me know if these ideas are sufficient to implement what you
> need. Also, any suggestions for better names, more examples, more use
> cases would be most appreciated.
> 
> The weak points that I see in my suggestions so far are (1) the need
> to define instruments in the correct order and (2) the need to use
> pmap to map scores to re-usable instrument pfields.
> 
> I do not see any solution for the first point aside from changing
> Csound orchestra parser internals which I do not wish to do. Therefore
> I am willing to live with this for the time being. This, obviously, is
> NOT an issue for a preprocessor.
> 
> The second point would be obviated if we could agree on a standard
> pfield format, but I think this would be very difficult.
> 
> Perhaps we could agree on a "suggested pfield format" but permit the
> use of pmap for extended pfield setups.
> 
> Regards,
> Mike
> 

I have done alot of this with something I called csound routines so maybe
that would be usefull it is sorta sloppy though I was learning python while
I was writing it and dex tracker isn't realy finished yet.  I look foward to
seeing the finished product maybe I will switch what I am doing over to it
(or I may write a converter).  I wasn't using templates it was just function
table renumbering, instrument renumbering and a little bit of the zak system
using the orc/sco files as a base..  convert to an int and find the next
spot available, covert back into a string with some commands in the comment
space (as suggested in a post many years earlier)


Jacob Joaquin wrote:
> 
> Reusing a Csound instrument in a new score typically involves copying and
> pasting the instrument into a new orchestra.  Once pasted, the user, more
> often than not, must make modifications to the instrument in order for it
> to work in its new environment.  Sometimes it is only a matter of changing
> the instrument number.  Other times, f-tables have to be ported and
> renumbered as well.  If there are software busses involve, such as zak,
> then modifications suddenly become a minor rewrite of the instrument.
> 
> No one enjoys this.  Well, statistically speaking, I'm sure there is a
> handful of people that do.  Though as a general rule, this is tedious work
> that most Csounders would rather do without.
> 
> I propose that we develop an instrument templating system for handling,
> importing and reusing instruments.
> 
> In a nutshell, an instrument template is basically a Csound instrument,
> minus an assigned instrument number, plus it can support additional
> variables the can be designated when constructed. Here is an example of
> what a Csound instrument template might look like:
> 
>     template Sinewave440
>         a1 oscils 1, 440, 1
>         out a1
>     end_template
> 
> In this very basic example, the code in the body is 100% Csound.  This is
> important because templates should look familiar to Csounders.  Templates
> would exist in an orchestra, or in an external file.  In order to use this
> template, an instrument must be created from it.  The code to do this
> might look like this:
> 
>     create_instr 1 Sinewave440
> 
> Or if the template exists in external file:
> 
>     import_template Sinewave440 from "./foo.orc"
>     create_instr 1 Sinewave440
>     
> The instrument as it is only works when nchnls is set to one. Since
> portability is a goal, I will modify this template to make it more of a
> general purpose template.  Instead of sending a1 to the dac using out, I
> will instead send it to an audio buss using the upcoming outleta opcode.
> 
>     template Sinewave262 #output
>         a1 oscils 1, 262, 1
>         outleta a1, #output
>     end_template
> 
> Here, I introduced template arguments.  The example uses one argument,
> #output.  What ever text is supplied as the first parameter will replace
> #output in the body of the template, much like a macro.
> 
>     create_instr 1 Sinewave262 "audio_out"
>     
> After the preprocessor, the following Csound code is produced:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
> To hear the audio, we still need to create an instrument that receives the
> audio and sends it to the dac or audio file.
> 
>     template StereoOut #left_input #right_input
>         a1 inleta #left_input
>         a2 inleta #right_input
>         output a1, a2
>     end_template
> 
>     create_instr 1 Sinewave262 "audio_out"
>     create_instr 2 StereoOut "audio_out" "audio_out"
>     
> After the preprocessor, the previous code would produce the following
> orchestra code:
> 
>     instr 1
>         a1 oscils 1, 262, 1
>         outleta a1, "audio_out"
>     endin
> 
>     instr 2
>         a1 inleta "audio_out"
>         a2 inleta "audio_out"
>         output a1, a2
>     endin
> 
> The greater implication is that instruments/templates could be used in a
> much more modular fashion.  Since numbers and buss names aren't assigned
> until an instr is created, Csounders would be able to patch together
> complex systems far easier and faster than is currently possible.
> 
> Here is a longer example that makes use of this theoretical patching
> system:
> 
>     template MySynth #output #fn
>         iamp = p4
>         ifreq = p5
>         ifn = #fn
>         
>         a1 oscil iamp, ifreq, ifn
>         outlet a1, #output
>     end_template
> 
>     template TheVerb #input #output #reverb_time
>         itime = #reverb_time
>         
>         a1 inleta #input
>         a1 reverb a1, itime
>         
>         outlet a1, #output
>     end_template
>     
>     template StereoOut #left #right
>         a1 inleta #left
>         a2 inleta #right
>         output a1, a2
>     end_template
> 
>     gir ftgen 33, 0, 8192, 10, 1
>     gir ftgen 34, 0, 8192, 7, -1, 8192, 1
>     
>     create_instr 1 MySynth "synth_out_1" 33
>     create_instr 2 MySynth "synth_out_2" 34
>     create_instr 3 TheVerb "synth_out_2" "verb_out" 2.23
>     create_instr 4 StereoOut "synth_out_1" "verb_out"
> 
> The score:
> 
>     i 1 0 4 0.5 440  ; sine, panned hard left
>     i 2 0 4 0.5 880  ; saw, panned hard right, sent to reverb
>     i 3 0 -1
>     i 4 0 -1
>     
> This is only the beginning of an idea, and much more thought is required. 
> Though I do believe that a system like this or similar would make Csound
> much more pleasant to work with, by leaps and bounds.  Imagine having a
> library with hundreds of user contributed templates / fully functional
> synths that anyone can plug into their orchestras and patch into other
> synths and DSPs, without the headaches of the current system.  That's the
> world I want to live in.
> 
> Best,
> Jake
>