Thanks for your summary.

All of the below, especially the API refactoring and the language support, 
would be much facilitated by changing the implementation language for Csound 
from C to C++.  I have mentioned this before. What I mean is that the top 
level of the API and the Csound "engine" calls should be C++ virtual 
classes. The code of existing Csound functions would not change very much, 
the main change in most cases would from from "csound->something" to 
"something", the logic and program flow within the functions would not need 
to change.

The reason for doing this is that it would simplify revision and maintenance 
of the API without impacting performance in any way (I know, I have done the 
required tests and research). Currently, adding new functions to the API or 
new members to the Csound structure requires coordinated changes to several 
different files which are not obvious except to experienced Csound 
developers. Changing from C structs to proper C++ classes would remove this 
complexity without adding any overhead. It would also make it easier to add 
to the API in future without breaking backward compatibility, which 
obviously has been an issue in the Csound API.

Another advantage of this is that SWIG could be applied to provide an 
interface to Csound internals from Python or Lua or other languages, which 
would aid in enabling other languages to compile Csound orchestras.

I am willing to do, or to participate in, this work.

It may or may not also be a good idea to change a number of internal Csound 
data structures from custom-built lists to collections from the standard C++ 
library. In both my lives as a programmer, financial programming and music 
programming, I have found the standard C++ library to be as fast as such 
custom structures and much less likely to generate bugs. I am talking about 
std::string, std::list, std::vector, and std::map.

Needless to say, in all that we do, backward compatibility for Csound pieces 
must remain priority one.

Regards,
Mike

----- Original Message ----- 
From: "Anthony Kozar" 
To: "New Csound Developer list" 
Sent: Thursday, February 05, 2009 10:38 PM
Subject: Re: [Cs-dev] some ideas for Csound 6


> Thanks Jonatan for starting this discussion again.  I am including a list 
> of
> ideas below that I think have all been suggested previously so that we do
> not have to spend a lot of time rehashing them.  Most of these ideas were
> proposed or elaborated on by other developers or users than myself.  They
> should make a good starting point for a "Csound 6 wish list".
>
> - multiprocessor/cluster support
> - finish new orchestra parser
> - multiple strings in score statements
> - new score parser ??
> - load or modify instruments during performance
> - move away from the command-line "batch mode" orientation of the API
>    - allow CSDs, orcs, scos to be read from strings in memory
>    - allow instruments and scores to be built programatically
>        - API calls to instantiate opcodes/signals and link them together
>        - merge Cscore and real-time event APIs (share data structs)
>        - embed a small scripting language (Lua?) so that instruments
>          and scores may be constructed directly within Orcs/Scos
>          without the need to write an API client
>    - allow setting options via API calls instead of building argv/argc
>    - eliminate the need for writing any temporary files to disk
>      (can still be an option for debugging)
>    - allow other Csound "objects" to be created, manipulated, and
>      destroyed with the API *without* having to instantiate a CSOUND
>      object and call csoundPerform().  eg. f-tables or utility analyses
>      so that external editors for these may more easily be written
> - alternative "functional style" for instrument code
> - support for other/modular language "front ends" to the Csound
>  engine (i.e. alternatives to Csound's orchestra and score langs);
>  this will not be difficult if all of the above are implemented
> - eg. a SAOL front-end
> - support for a SAOL-like "control" event in the score
> - API support for sending control signals to specific instrument instances
> - arrays of opcodes and signals
> - "always on" instruments (instantiated from orchestra, not score) ?
> - SIMD support ?
> - move obsolete, redundant, buggy, and confusing opcodes into a
>  "deprecated" plugin module that users could install for backwards
>  compatibility but which would discourage their use in new pieces
>
> For my part, I think support for Mac OS 9 could be dropped so that
> threading, networking, and other advanced features can be implemented
> without #ifdefs and stubs.
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
>
> Jonatan Liljedahl wrote on 2/5/09 3:13 PM:
>
>> Here's some ideas for Csound 6:
>
>
> ------------------------------------------------------------------------------
> 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

michael.gogins@gmail.com wrote on 2/6/09 7:45 AM:

> All of the below, especially the API refactoring and the language support,
> would be much facilitated by changing the implementation language for Csound
> from C to C++.  I have mentioned this before.

I expected this to come up again :)

> The code of existing Csound functions would not change very much,
> the main change in most cases would from from "csound->something" to
> "something", 

Or "this->something".

> The reason for doing this is that it would simplify revision and maintenance
> of the API without impacting performance in any way (I know, I have done the
> required tests and research).

It is not clear to me that this is true, but that may be partially due to
ignorance on my part.  Please elaborate on how it would help.

> Currently, adding new functions to the API or
> new members to the Csound structure requires coordinated changes to several
> different files which are not obvious except to experienced Csound
> developers. 

This is certainly true -- and it is error prone even for us "experienced
Csound developers".

> Changing from C structs to proper C++ classes would remove this
> complexity without adding any overhead.

How does it remove the complexity?  Although it has been 5.5 years now since
I have really used C++, I learned C++ before learning C, and I remember it
being quite complex and a royal pain at times.  Everytime that I had to
create a new data structure, if I wanted to do it "properly", it would
involve creating a class with a header file and an implementation file,
private data members, accessor functions for every data member, etc.  It was
so much more work than creating a C struct that I tried to write my own
"Class Wizard" program to alleviate some of the tedium.

That was my experience at times.  I am not saying that I cannot be persuaded
that C++ could be better for Csound.

> It would also make it easier to add
> to the API in future without breaking backward compatibility, which
> obviously has been an issue in the Csound API.

Won't we have the same problems if someone reorders class members or inserts
a new one in the middle of the class definition?  I don't really know a lot
about how the dynamic linker works with C++ but I thought it would be
fraught with the same dangers.

And my biggest concern here is the incompatible ABIs for C++ with different
versions of GCC.  Almost every version of Mac OS X has come with a different
version of GCC, and half of those have broken compatibility of C++ code
linked with older versions.  Currently, I believe that C hosts and plugins
can be linked to Csound on OS X even if they are built with a different GCC.
Converting to C++ would probably eliminate that.  OS X users are reliant on
Apple's supplied GCC.  While Apple usually supplies at least the current and
the previous versions of their GCCs, they don't make it easy to support a
wide range of OS X versions if the developer is using current tools.  But
since we have yet to have anyone complain about current Csound distributions
only running on Mac OS X 10.4 and later, maybe this will not be such a big
problem.

> Another advantage of this is that SWIG could be applied to provide an
> interface to Csound internals from Python or Lua or other languages, which
> would aid in enabling other languages to compile Csound orchestras.

How would this be better than the SWIG wrappers we have now?

> It may or may not also be a good idea to change a number of internal Csound
> data structures from custom-built lists to collections from the standard C++
> library. In both my lives as a programmer, financial programming and music
> programming, I have found the standard C++ library to be as fast as such
> custom structures and much less likely to generate bugs. I am talking about
> std::string, std::list, std::vector, and std::map.

Now this I agree with.  While working on the Mac OS 9 Csound front end
(written in C), I got very frustrated with how much of my time was spent
reinventing the wheel.  Every time that I needed a linked list, map,
flexible array, etc., I would have to write that code from scratch again.  I
also needed a system of function pointers for various user interface
elements that basically reimplemented C++ virtual functions.  I contemplated
converting the entire project to C++ many times, however I was already
frustrated by lack of progress on new features because I was spending too
much time rewriting old code that I was loath to invest time in such a major
change.

Perhaps the biggest problem though with changing to C++ is that some members
of our team are not comfortable with it.  If it impairs the ability of some
of Csound's biggest contributors to continue working on the project, then I
think it would be a net loss, no matter how significant the other gains
would be.  

I can some benefits to changing to C++, but I am not yet convinced that it
would be the right choice.

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

Thanks for your thoughtful response. My replies are below.

>> The reason for doing this is that it would simplify revision and maintenance
>> of the API without impacting performance in any way (I know, I have done the
>> required tests and research).
>
> It is not clear to me that this is true, but that may be partially due to
> ignorance on my part.  Please elaborate on how it would help.

Other things being equal, C++ code executes as fast as C code, because
C++ compilers use more or less the same methods and technologies as C
compilers. This has been verified by myself and by many others.

Other things are not equal, of course, and people use C++ because of
its object orientation, which adds a small performance overhead. A
virtual method dispatch takes the same code as a regular function call
dispatch plus one pointer dereference and possibly one pointer
addition or offset. I am recommending that the C++ API and internals
become virtual classes because it will simplify the development and
maintenance of the code. I am confident that the small additional
overhead incurred will be (a) worth it, and (b) probably more than
made up for by subsequent simplification of the code. Simplification
of code turns into speed because fewer instructions are generated by
the compiler.

C++ is well known to simplify the development of large projects while
still generating high-performance code. Most large commercial projects
use C++ instead of C for exactly these reasons. Many scientific
computing projects and military projects also use C++ for these
reasons.  For how the simplification happens, see the following items.

>> Currently, adding new functions to the API or
>> new members to the Csound structure requires coordinated changes to several
>> different files which are not obvious except to experienced Csound
>> developers.
>
> This is certainly true -- and it is error prone even for us "experienced
> Csound developers".
>
>> Changing from C structs to proper C++ classes would remove this
>> complexity without adding any overhead.
>
> How does it remove the complexity?  Although it has been 5.5 years now since
> I have really used C++, I learned C++ before learning C, and I remember it
> being quite complex and a royal pain at times.  Everytime that I had to
> create a new data structure, if I wanted to do it "properly", it would
> involve creating a class with a header file and an implementation file,
> private data members, accessor functions for every data member, etc.  It was
> so much more work than creating a C struct that I tried to write my own
> "Class Wizard" program to alleviate some of the tedium.

C++ is complex and painful, but the complexity and pain can be avoided
by following some fairly simple rules. There is no need to do things
"properly" in Csound because we would not be generating new classes in
accordance with some rigid notion of C++ style, we would be porting
existing code from structs and functions into classes and member
functions. For the most part this would mean changing

typdef struct CSOUND_
{
} CSOUND;

int csoundFunction(CSOUND *csound, int p1, double p2, char *p3);

to

class CSOUND
{
  virtual int csoundFunction(int p1, double p2, const char *p3);
};

and inside CSOUND::csoundFunction pasting all existing code and replacing

csound->

either with "this->" or with nothing.

That's pretty much it. Seems simple to me. Another source of
simplification is use of the standard C++ library for data structures,
which you acknowledge below.

>> It would also make it easier to add
>> to the API in future without breaking backward compatibility, which
>> obviously has been an issue in the Csound API.
>
> Won't we have the same problems if someone reorders class members or inserts
> a new one in the middle of the class definition?  I don't really know a lot
> about how the dynamic linker works with C++ but I thought it would be
> fraught with the same dangers.

For the dynamic linker, a C++ function is just a C function, and in
most C++ ABIs, the "this" pointer is just a pointer to the beginning
of the class. If the class has virtual functions, the beginning of the
class is a pointer to the virtual function table.

The simple guideline here is: access internals only through virtual
functions, and add new virtual functions only at the end of class
declarations. Then backward compatibility is complete.

In Csound we can relax this and permit the addition of new public data
members, also at the end of the class declarations.

In the existing CSOUND struct, we do not have a single pointer to a
table of function pointers, we have individual function pointers. This
was a big mistake (by me, I have to admit - I didn't know as much when
I started with Csound development as I do now).

In fact -- and let me stress this -- if we do not port Csound to C++,
we should still go ahead and move all the Csound functions into a
function table or tables. This in itself would make Csound code easier
to maintain.

>
> And my biggest concern here is the incompatible ABIs for C++ with different
> versions of GCC.  Almost every version of Mac OS X has come with a different
> version of GCC, and half of those have broken compatibility of C++ code
> linked with older versions.  Currently, I believe that C hosts and plugins
> can be linked to Csound on OS X even if they are built with a different GCC.
> Converting to C++ would probably eliminate that.  OS X users are reliant on
> Apple's supplied GCC.  While Apple usually supplies at least the current and
> the previous versions of their GCCs, they don't make it easy to support a
> wide range of OS X versions if the developer is using current tools.  But
> since we have yet to have anyone complain about current Csound distributions
> only running on Mac OS X 10.4 and later, maybe this will not be such a big
> problem.

Yes, C++ ABI compatibility can be fragile. The API should continue to
exist in C as well as C++. This fragility has to do both with bits of
support code that get statically linked into C++ programs, and also
with name mangling. For dynamic linking, the support code bits are not
a problem, and the name mangling does not change often, so it also
shouldn't be much of a problem. If the compiler changes the size or
location of the virtual function pointer, that can be a problem. This
has happened with the Microsoft compiler, but as far as I know, it has
not happened with GCC.

In this case the simple guidelines are: declare all class member
functions virtual, do not use multiple inheritance in API classes, and
use dynamic linkage.

It may be possible to simply type cast the C++ API functions directly
to C functions, such that

int (CSOUND::*someFunction)(int p1, double p2, const char *p3)

becomes

int (*someFunction)(void* csound, int p1, double p2, const char *p3)

or we write a bunch of simple C functions that call the C++ functions.

>> Another advantage of this is that SWIG could be applied to provide an
>> interface to Csound internals from Python or Lua or other languages, which
>> would aid in enabling other languages to compile Csound orchestras.
>
> How would this be better than the SWIG wrappers we have now?

These would be wrappers for the internal portions of Csound, not just
the external API.  It would be done so that people could write
instruments and opcodes in Python (or whatever language).

>> It may or may not also be a good idea to change a number of internal Csound
>> data structures from custom-built lists to collections from the standard C++
>> library. In both my lives as a programmer, financial programming and music
>> programming, I have found the standard C++ library to be as fast as such
>> custom structures and much less likely to generate bugs. I am talking about
>> std::string, std::list, std::vector, and std::map.
>
> Now this I agree with.  While working on the Mac OS 9 Csound front end
> (written in C), I got very frustrated with how much of my time was spent
> reinventing the wheel.  Every time that I needed a linked list, map,
> flexible array, etc., I would have to write that code from scratch again.  I
> also needed a system of function pointers for various user interface
> elements that basically reimplemented C++ virtual functions.  I contemplated
> converting the entire project to C++ many times, however I was already
> frustrated by lack of progress on new features because I was spending too
> much time rewriting old code that I was loath to invest time in such a major
> change.
>
> Perhaps the biggest problem though with changing to C++ is that some members
> of our team are not comfortable with it.  If it impairs the ability of some
> of Csound's biggest contributors to continue working on the project, then I
> think it would be a net loss, no matter how significant the other gains
> would be.

Well, let's see. If John ffitch or whoever doesn't like it, it won't
fly. I have no interest in alienating any committed Csound developers,
and I'm not going to spend lots and lots of my time arguing it.

I can only re-iterate: I am not a "trend" type of man. I have no
personal bias in favor of any language.  I try to base technical
decisions on science and experience with respect to solving concrete
problems. I have decades of professional experience in programming in
many languages, including both C and C++, and in music programming. I
can tell you that in my experience C++ is a better language for music
programming and a better language for large projects. Most military
DSP developers, physics data processing developers, and commercial
music software developers evidently agree with me.

-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
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:
..
..
> 
>> It would also make it easier to add
>> to the API in future without breaking backward compatibility, which
>> obviously has been an issue in the Csound API.
> 
> Won't we have the same problems if someone reorders class members or inserts
> a new one in the middle of the class definition?  I don't really know a lot
> about how the dynamic linker works with C++ but I thought it would be
> fraught with the same dangers.
> 

I had always hoped we could eliminate the CSOUND  struct from the API 
altogether by using the QueryInterface paradigm (which is not dependent 
on C++ but is kind of popularly associated with it as an OOP model, not 
least thanks to COM); but I guess that is an old story now. It would 
have enabled arbitrary additions and deletions to be made to internal 
code without affecting the API at all - as a new facility is created, 
host apps would simply QueryInterface for it, and if found use it, if 
not tell the user but carry on with plan B anyway. If we moved to C++ 
but kept the current CSOUND struct dependency, it will only ever be 
C++ish at best, and in all probavbility still need apps to be rebuilt 
each time the struct is changed. I still suspect that  whole chunks of 
internal quasi-global variables currently in the CSOUND struct can be 
eliminated by refactoring internal function calls to pass parameters and 
return things - something I started exploring many years ago, but got 
sort of overtaken by events.



.. OS X users are reliant on
> Apple's supplied GCC.  

Come to it, Apple's "native" language is not C++ but Objective-C  (under 
their Cocoa wrapper) and GUI developers in particular are being strongly 
encouraged to move to Objective-C/Cocoa wherever possible.

..
> I can some benefits to changing to C++, but I am not yet convinced that it
> would be the right choice.
> 

It begs the question of which (if any!) flavour of C/C++ is really going 
to be the language of a multiprocessor+audio future, with concurrent 
message-passing languages such as Erlang (runtime dynamic code 
replacement anyone?) coming up fast. In any case, anyone contemplating a 
move to C++ should be looking hard at the forthcoming C++0x standard, 
which may well be ratified this year. While not exactly going all the 
way, it is aiming to make multi-threaded programming a standard built-in 
facility (though still dependent on the  much-expanded standard library 
rather than fully at the level of the language itself) -  built-in 
atomics, etc. In the meantime, I will be more than happy to see Csound 
continue in ANSI C (which is itself steadily being supplanted in some 
quarters by the somewhat chimeric C99).

Richard Dobson



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

Richard Dobson wrote:
> 
> Anthony Kozar wrote:
> 
> I still suspect that  whole chunks of 
> internal quasi-global variables currently in the CSOUND struct can be 
> eliminated by refactoring internal function calls to pass parameters and 
> return things
> 
> 

This is the point.

Before coding again, specifications for the instrument 
template, a memory layout, need to be defined and 
documented. Also, i see five main entities:

the csParser (csScoreParser, csOrchestraParser)
the csEventListener or csEventSensor
the csPlayer or csPerformer
the csInstrument
the csScore

each of them handling their own data.


csOrchestraParser creates the instrument template
instance, creating a csInstrument and adding it
to a csInstrument list (instrument pool)

csEventListener selects the csInstrument in the
pool activating it. It adds it to a second
csInstrument list (active instrument list).

csPlayer traverses the active instrument list
giving each opcode the chance to perform.

csOrchestraParser is not the only source of
instruments. Any other technique (complying with
the specifications) may create a csInstrment
and (dinamically as well) add it to the pool.

It's not a matter of C or C++, it's a matter
of defining and separating the tasks.
C++ STL could be very useful. If C++ is not
used, general functions that handle a List
(and the like) should be developed anyway.



-- 
View this message in context: http://www.nabble.com/Channels-tp21852607p21886378.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


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

Yes, this kind of separation could be very good for Csound in the long run.
I am a little worried that the temptation to take the most expedient route
will drive us to implement major new features such as the dynamic instrument
loading in a "hackish" manner without significantly modifying the current
internals.  Doing a thorough refactoring could take a long time.

I am sure that there are other features that people would like to add that
belong properly to "Csound 6" because they will require significant API
changes, but that may take much less time than a full refactorization.  I am
guessing that John brought up the Channels API question the other day
because he was actually ready to sit down and start changing it.  I don't
know how we should plan to accommadate both short and long term API changes.

A clear roadmap for Csound 6 -- and possibly Csound 7 -- would give us
something to work towards and would allow developers to make choices about
the best use of their time.

Any suggestions?

Anthony

Pinball wrote on 2/7/09 4:17 AM:

> Richard Dobson wrote:
>> 
>> I still suspect that  whole chunks of
>> internal quasi-global variables currently in the CSOUND struct can be
>> eliminated by refactoring internal function calls to pass parameters and
>> return things
>> 
>> 
> 
> This is the point.
> 
> Before coding again, specifications for the instrument
> template, a memory layout, need to be defined and
> documented. Also, i see five main entities:
> 
> the csParser (csScoreParser, csOrchestraParser)
> the csEventListener or csEventSensor
> the csPlayer or csPerformer
> the csInstrument
> the csScore
> 
> each of them handling their own data.


------------------------------------------------------------------------------
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-2 wrote:
> 
> Yes, this kind of separation could be very good for Csound in the long
> run.
> I am a little worried that the temptation to take the most expedient route
> will drive us to implement major new features such as the dynamic
> instrument
> loading in a "hackish" manner without significantly modifying the current
> internals.  Doing a thorough refactoring could take a long time.
> 
> I am sure that there are other features that people would like to add that
> belong properly to "Csound 6" because they will require significant API
> changes, but that may take much less time than a full refactorization.  I
> am
> guessing that John brought up the Channels API question the other day
> because he was actually ready to sit down and start changing it.  I don't
> know how we should plan to accommadate both short and long term API
> changes.
> 
> A clear roadmap for Csound 6 -- and possibly Csound 7 -- would give us
> something to work towards and would allow developers to make choices about
> the best use of their time.
> 
> Any suggestions?
> 

A)

Short term changes in CSound 5.xx
(Not so) Long term changes in CSound 6.xx
INSTRs vs UDOs in CSound 7.xx

?


B)

I also wish CSound could be compiled with MSVC++


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.


What will the Instrument Data Format look like? A chunk of 
memory with a list of opcodes followed by in/out argument
references? It should be stored and loaded later, eventually 
resolving the opcode addresses and arguments (instances)
Where in memory are the arguments stored? What about 
arguments tables?


-- 
View this message in context: http://www.nabble.com/Channels-tp21852607p21897809.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


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

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.
 
> B)
> 
> I also wish CSound could be compiled with MSVC++

Many people might like this (and many would no doubt want a simple Xcode
project for Mac OS X too), but it is a fact that maintaining multiple build
systems is a pain and more work than is worthwhile for our small developer
team.  I did maintain a separate build system for Mac OS 9 for several years
and I can attest to the difficulty of making sure it was in sync with the
SCons system.  If there are people who want to contribute MSVC or Xcode
projects _and_keep_them_up_to_date_, then they are welcome to do so.

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

I do not know that it is such a good idea to allow saving compiled
instrument data in a file or to make Csound's internal data structures for
that data publicly available via the API.  We _do_ want to provide API
functions for building and manipulating instruments.  But we do not have to
make the internal structures visible to do that.  Making the structures
public or saving them to file would severely limit our ability to change
them as needed, which could impair future optimizations or new features.  If
we allowed saving the data in a file, it would also be difficult to ensure
compatibility between different architectures (Intel, PPC, 32-bit, 64-bit,
etc.)

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


------------------------------------------------------------------------------
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-2 wrote:
> 
> Pinball wrote on 2/8/09 6:17 AM:
> 
>> 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.
> 
> I do not know that it is such a good idea to allow saving compiled
> instrument data in a file or to make Csound's internal data structures for
> that data publicly available via the API.  We _do_ want to provide API
> functions for building and manipulating instruments.  But we do not have
> to
> make the internal structures visible to do that.  Making the structures
> public or saving them to file would severely limit our ability to change
> them as needed, which could impair future optimizations or new features. 
> If
> we allowed saving the data in a file, it would also be difficult to ensure
> compatibility between different architectures (Intel, PPC, 32-bit, 64-bit,
> etc.)
> 
> 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
> 


A compiled instrument is still just a template.
When i say binary, i don't mean an executable
or a piece of C/C++ compiled code. Picture it 
like Java's bytecode.

After compilation the instrument sleeps in the
pool still being a template: an IDESCRIPTOR. 
Once activated, it becomes the "non portable" 
memory chunk that, as you say, should not be 
exported (IDATA). Every dynamic update is 
handled by the csInstrument altering the 
IDESCRIPTOR layout that it manages. 


TEXT -> IDESCRIPTOR -> IDATA
GUI -> IDESCRIPTOR -> IDATA

You design an instrument: TEXT or GUI
You compile the instrument and get an IDESCRIPTOR.
An event activates the instrument producing the IDATA.


-- 
View this message in context: http://www.nabble.com/Channels-tp21852607p21904893.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
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-2 wrote:
> 
> Pinball wrote on 2/8/09 6:17 AM:
> 
>> 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.
> 
> I do not know that it is such a good idea to allow saving compiled
> instrument data in a file or to make Csound's internal data structures for
> that data publicly available via the API.  We _do_ want to provide API
> functions for building and manipulating instruments.  But we do not have
> to
> make the internal structures visible to do that.  Making the structures
> public or saving them to file would severely limit our ability to change
> them as needed, which could impair future optimizations or new features. 
> If
> we allowed saving the data in a file, it would also be difficult to ensure
> compatibility between different architectures (Intel, PPC, 32-bit, 64-bit,
> etc.)
> 
> 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
> 


A compiled instrument is still just a template.
When i say binary, i don't mean an executable
or a piece of C/C++ compiled code. Picture it 
like Java's bytecode.

After compilation the instrument sleeps in the
pool still being a template: an IDESCRIPTOR. 
Once activated, it becomes the "non portable" 
memory chunk that, as you say, should not be 
exported (IDATA). Every dynamic update is 
handled by the csInstrument altering the 
IDESCRIPTOR layout that it manages. 


TEXT -> IDESCRIPTOR -> IDATA
GUI -> IDESCRIPTOR -> IDATA

You design an instrument: TEXT or GUI
You compile the instrument and get an IDESCRIPTOR.
An event activates the instrument producing the IDATA.


-- 
View this message in context: http://www.nabble.com/Channels-tp21852607p21904895.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


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

Pinball wrote on 2/8/09 6:37 PM:

> A compiled instrument is still just a template.
> When i say binary, i don't mean an executable
> or a piece of C/C++ compiled code. Picture it
> like Java's bytecode.

The "compilation" process in Csound does indeed produce an instrument
template but it like neither C/C++ object code, nor Java bytecode.  It is
just (binary) data.  Csound never produces executable code from anything.
In this sense, it is unlike many other Music N programs (CLM, Cmusic, etc.)

> After compilation the instrument sleeps in the
> pool still being a template: an IDESCRIPTOR.
> Once activated, it becomes the "non portable"
> memory chunk that, as you say, should not be
> exported (IDATA).

The templates that Csound currently produces are already non-portable binary
structures.  They could be made portable, but being a binary format, they
would still have all of the problems previously mentioned.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/


------------------------------------------------------------------------------
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-2 wrote:
> 
> Pinball wrote on 2/8/09 6:37 PM:
> 
> 
>> After compilation the instrument sleeps in the
>> pool still being a template: an IDESCRIPTOR.
>> Once activated, it becomes the "non portable"
>> memory chunk that, as you say, should not be
>> exported (IDATA).
> 
> The templates that Csound currently produces are already non-portable
> binary
> structures.  They could be made portable, but being a binary format, they
> would still have all of the problems previously mentioned.
> 

What is an IDESCRIPTOR if not the description of the graph
you're looking for, that is not scattered here and there and
that abstracts from the implementation, carrying within itself
all the knowledge to let the developers handle it over time.


-- 
View this message in context: http://www.nabble.com/Channels-tp21852607p21910470.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


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