My comments below.

----- Original Message ----- 
From: "Anthony Kozar" 
To: "New Csound Developer list" 
Sent: Sunday, February 08, 2009 11:08 AM
Subject: Re: [Cs-dev] some ideas for Csound 6


> Pinball wrote on 2/8/09 6:17 AM:
>
>> A)
>>
>> Short term changes in CSound 5.xx
>> (Not so) Long term changes in CSound 6.xx
>> INSTRs vs UDOs in CSound 7.xx
>
> This might be a reasonable plan.  I'm not sure how close the modifications
> for dynamically loaded instruments (DLIs) -- which I assume people want 
> for
> Csound 6 -- will put us to implementation of a generic DAGUG ("directed
> acyclical graph of unit generators") that will be necessary for so many of
> the other ideas that are being discussed.  If generic DAGUGs will require 
> a
> great deal more work beyond DLIs, then it might be reasonable to put them 
> on
> the roadmap for Csound 7.

Modifications for DLI are logically independent of modifications for DAGUG. 
A unit generator in a DAGUG could have an abstract interface suited for 
loading from a shared library, and so could a DLI. Thus, a DAGUG could and 
should have two types of node interfaces, of which one would be a DLI.

>> C)
>>
>> 1) The instrument source (a text file)
>> 2) The instrument code (bin file)
>> 3) The orchestra source (a collection of instruments sources)
>> 4) Whatever source
>>
>> will all translate into Instrument Data (IDATA) (the bin file
>> itself ?). An Instrument Data Format (IDF) must be defined.
>>
>> So, independently of the sources, the csPerformer will play
>> a chain of IDATA chunks at k-time, running the opcodes each
>> IDATA is associated with.
>

This is not a good idea. Saved data should be textual or, failing that, in 
some utterly standard binary format (like a MIDI file or a soundfile). Other 
binary formats will break over time.

> I can see allowing a host application to retain an opaque pointer to the
> compiled instrument data for as long as it is running so that an orchestra
> can be reused without recompiling.  But I would recommend against any 
> course
> of action that would require that data to remain compatible across 
> multiple
> runs of Csound, between the same version of Csound on different
> architectures, and especially between multiple releases of Csound.
>
> Anthony

I agree, reason stated above.



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

Maybe I am not fully understanding your intention with the DAGUG idea then.
I was assuming that all nodes in the DAGUG would be Csound opcodes or
special mixing and routing nodes.  I was going off of this previous post you
made:



While loading plugin instruments in CLM style (as shared libraries) is an
intriguing idea, what do you think that it would gain for us over loading
the same code as a plugin opcode?  An opcode can be arbitrarily complex and
is "patchable" via the orch language.

Anthony

michael.gogins@gmail.com wrote on 2/8/09 11:38 AM:

> Modifications for DLI are logically independent of modifications for DAGUG.
> A unit generator in a DAGUG could have an abstract interface suited for
> loading from a shared library, and so could a DLI. Thus, a DAGUG could and
> should have two types of node interfaces, of which one would be a DLI.


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