Thanks again for your thoughts. My comments:

1. I have discussed C++ already.

2. Sample accurate scheduling can be done in the same manner as Synz -- the 
DSP graph starts out doing N sample frames, an event intervenes at frame J, 
the DSP graph finishes computing frame J and starts another round of N 
frames starting with the new event.

3, 4, and 5 are the same thing, most properly called "directed acyclical 
graph of unit generators." However, as I believe Steven Yi mentioned, it is 
in fact advisable to retain the notion of "instrument." This is especially 
so because of the need in Csound for dynamic allocation of new instances of 
instruments for newly occuring notes in polyphonic music. An "instrument" 
can be a special kind of node in the DSP graph that contains its own 
sub-graph of multiple instances of a template instrument.

6 is interesting, I need to think about this.

Regards,
Mike

----- Original Message ----- 
From: "Anthony Kozar" 
To: "New Csound Developer list" 
Sent: Saturday, February 07, 2009 8:35 PM
Subject: Re: [Cs-dev] some ideas for Csound 6


>I suppose the SAOL control events might seem limited, but from the
> perspective that you can change any variable in an instrument without
> preparing the instrument for such control, they are quite flexible over
> Csound.  In practice, such tweaking may not be useful without some
> forethought since most parameter changes need to be continuous to avoid
> clicks.  But still, it is a simple matter to ensure continuity with a
> portamento opcode.
>
> Anyways, a more flexible facility would be fine too.  Even if the Csound
> score language is not augmented to support it, if the Csound engine can
> support the SAOL-like control feature (or more), then it will be possible 
> to
> have a SAOL language interpreter with Csound as the back end.
>
> I have been combing through old musings on Csound 6, and here are some
> additional ideas that have been proposed:
>
> 1. convert Csound core to C++
> 2. sample accurate scheduling
> 3. allow a "full directed acyclical DSP graph", in place of instrument
>   list/opcode list type graph.
> 4. remove the distinction between instruments and UDOs
> 5. flexible output routing for instruments without using globals, buses, 
> zak
> 6. orch opcodes as arguments to score statements:
>
>    instr 1
>        asig oscil p4, p5, 1
>             out   asig
>    endin
>
>    i1 0 2 7500 440.0
>    i1 1 1 [[line 0, p3, 7500]]  [[kp5 expon 330.0, p3, 220.0]]
>
>
> The last of these would be another way of achieving more score control 
> over
> instruments without preparation.  No. 3 from this list would probably 
> enable
> Nos. 4, 5, and 6.  It might be difficult to both implement these 
> suggestions
> in an elegant way and maintain backwards compatibility with the existing
> orchestra and score languages.  In that case, I think as long as the 
> engine
> supports modifying individual instances of instruments (and Michael's
> concept in #3), then we could provide two parallel options in Csound 6: 
> 1)
> the traditional orc/sco model, and 2) a new language that blends synthesis
> and event control with greater flexibility than the traditional model and
> hopefully none of its baggage.
>
> I'm sure all of this is vague -- I'd be happy to elaborate :)
>
> Anthony
>
> Steven Yi wrote on 2/7/09 3:20 PM:
>
>> If I understand correctly, SAOL control events seem very limited in
>> that they only change the value discretely.  I saw no option to slowly
>> change over time linearly or with any other curve.  If we did
>> implement something in csound this way, I would say we would need some
>> method to change the value over time, but likely that would lead to
>> just doing what blue does and having an instrument to do that work.
>> One thing blue has to do is generate an instrument for every variable
>> as it has to get compiled down that way; this might be a case for
>> having the variables names maintained so that variables can be queried
>> by name, so that a single instrument could be used for any number of
>> variables.
>
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with 
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code 
> to
> build responsive, highly engaging applications that combine the power of 
> local
> resources and data with the reach of the web. Download the Adobe AIR SDK 
> and
> Ajax docs to start building applications 
> today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thank you for your thoughts too, Michael :)  I am glad that you have some
ideas on the sample accuracy problems, because that seemed like a tricky one
to me.

3, 4, and 5 _are_ close to the same thing (and 6 is not far from the
others).  While they might all share the same implementation methods, they
could differ from each other in how they are represented in Csound's input
language(s).

Certainly the notion of an instrument is useful.  But it is not much
different than the notion of a user-defined opcode.  UDOs explicitly specify
their input and output arguments.  An instrument is similar to an UDO with
three sets of implied arguments:

    a) a set of i-rate inputs (p4, p5, ...)
    b) usually a set of a-rate outputs indicated by an out* opcode
    c) possibly a set of a-rate inputs indicated by an in* opcode

It differs from an UDO because it is stored as an instrument template for
instantiation which happens when it is invoked from the score, at which time
it also receives two (three) special i-rate parameters: p2, p3, (p1).  If we
had templates for UDOs and they were invocable from the score, then they
would be usable as instruments.  In fact, I believe they would be more
powerful than the instruments that we have now since they could take
parameters of any type, not just i-rate.  This is where I see the
distinction between orchestra and score beginning to blur.

Here is what we would need:

1) All blocks of orchestra code defined with explicit parameters similarly
to UDOs but they would have instantiable templates internally.  They could
also be called like UDOs by other blocks.  Whether we use "opcode" or
"instr" to begin the block is not important.  Let's call them "instruments".

2) Top-level orchestra "primitives" for routing and mixing the outputs of
the instruments.  (Top-level, as in "instr 0" in the current parlance).
These should not be conceived of as opcodes per se, but would specify the
creation of nodes in the DSP graph where the output of dynamic groups of
instrument instances would be collected which might become the inputs of
other instruments in the graph or be sent to the "main outs".

3) A way to instantiate any block at a specified time for a specified
duration.  This could be in the score or the top-level of the orchestra
again.  Unique patching of all input and output parameters should be
possible for each instance when adding it to the DSP graph.  Missing
arguments would be determined by (2) and by built-in defaults (such as
a-rate outputs going to the "main outs" in order).

4) To enable #6 on my previous list, "anonymous instruments" -- previously
undefined blocks of code -- could also be be patched into the ins or outs of
an instrument instance as it is created.  This further mixing of the roles
of orchestra and score might imply that they should be merged into one
language.  Users who like the orc/sco dichotomy could continue to put the
appropriate code into separate files if desired.
    
I'm sure that this is still vague and might be misinterpreted.  I'll try to
write up an example of what this might all look like with a fuller
explanation.  I think that this model would encompass many of the
suggestions made by various people.  In all honesty, it sounds similar to
what I know about Supercollider ...

Anthony

michael.gogins@gmail.com wrote on 2/7/09 9:16 PM:

> Thanks again for your thoughts. My comments:
> 
> 1. I have discussed C++ already.
> 
> 2. Sample accurate scheduling can be done in the same manner as Synz -- the
> DSP graph starts out doing N sample frames, an event intervenes at frame J,
> the DSP graph finishes computing frame J and starts another round of N
> frames starting with the new event.
> 
> 3, 4, and 5 are the same thing, most properly called "directed acyclical
> graph of unit generators." However, as I believe Steven Yi mentioned, it is
> in fact advisable to retain the notion of "instrument." This is especially
> so because of the need in Csound for dynamic allocation of new instances of
> instruments for newly occuring notes in polyphonic music. An "instrument"
> can be a special kind of node in the DSP graph that contains its own
> sub-graph of multiple instances of a template instrument.
> 
> 6 is interesting, I need to think about this.
> 
> Regards,
> Mike
> 
> ----- Original Message -----
> From: "Anthony Kozar" 

>> I have been combing through old musings on Csound 6, and here are some
>> additional ideas that have been proposed:
>> 
>> 1. convert Csound core to C++
>> 2. sample accurate scheduling
>> 3. allow a "full directed acyclical DSP graph", in place of instrument
>>   list/opcode list type graph.
>> 4. remove the distinction between instruments and UDOs
>> 5. flexible output routing for instruments without using globals, buses,
>> zak
>> 6. orch opcodes as arguments to score statements:
>> 
>>    instr 1
>>        asig oscil p4, p5, 1
>>             out   asig
>>    endin
>> 
>>    i1 0 2 7500 440.0
>>    i1 1 1 [[line 0, p3, 7500]]  [[kp5 expon 330.0, p3, 220.0]]
>> 
>> 
>> The last of these would be another way of achieving more score control
>> over
>> instruments without preparation.  No. 3 from this list would probably
>> enable
>> Nos. 4, 5, and 6.  It might be difficult to both implement these
>> suggestions
>> in an elegant way and maintain backwards compatibility with the existing
>> orchestra and score languages.  In that case, I think as long as the
>> engine
>> supports modifying individual instances of instruments (and Michael's
>> concept in #3), then we could provide two parallel options in Csound 6:
>> 1)
>> the traditional orc/sco model, and 2) a new language that blends synthesis
>> and event control with greater flexibility than the traditional model and
>> hopefully none of its baggage.


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote on 2/7/09 10:37 PM:

> [An instrument] differs from an UDO because it is stored as an instrument
> template [...]  If we had templates for UDOs and they were invocable from the
> score, then they would be usable as instruments.

I've been looking at the code and see that templates are created for UDOs.
That makes sense ... they have to be stored somehow before being inserted
into actual instruments.  But my point about UDOs being invocable from the
score is the important part.  The key is to have a mechanism for providing
k-rate and a-rate arguments to UDO/instruments.  I believe this will be
possible with a generic DAGUG architecture as proposed by Michael and some
new syntax conventions.

More to come ...

Anthony


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net