There are many kinds of memory allocation. The standard in high-performance 
batch processing is a heap with named variables, but no memory is ever 
deallocated until the batch is finished. In this case, there is no need to 
monkey with the heap until processing is finished. The allocator just moves 
a pointer forward in the heap for each allocation of a variable, period. It 
is as fast as Csound but you get the map of names to objects as well.

Regards,
Mike

----- Original Message ----- 
From: "Steven Yi" 
To: "Developer discussions" 
Sent: Friday, February 06, 2009 12:23 AM
Subject: Re: [Cs-dev] some ideas for Csound 6


>I would say that the most interesting things to me would be getting
> the parser done, which would open up the way to getting instruments to
> be programmatically created. The reason I see it this way is that the
> new parser code is much simpler IMO to see how everything is working
> when it parses then compiles down the code, as it already works in two
> passes (build AST, compile).  If that's finished, it should be easy to
> change how the compilation step works, then removing the mass
> allocation of memory for all variables and the erasure of what
> variables are set to what addresses.  If we replace that with
> something that looks more like scripting engine's allocation of
> variables one at a time in a Map, we could then do some dynamic
> instrument creation/modification as we could then have access to the
> variables by name.
>
> Downside to that is an impact on performance.  It'd really only impact
> allocation of new instruments though, and with today's computers at
> the speed they are, I'd imagine it being more valuable to have the
> ability to modify instruments than to improve instrument allocation
> time. Another downside is that we wouldn't be able to highly optimize
> the compiled code to do things like dead code elimination or
> expression optimization, as we'd need a way to undo that if
> instruments change.  Perhaps the engine could be created to run with a
> compiled mode for speed or a scripting mode for live changes.
>
> If we move to creating instrument dynamically, then it shouldn't be a
> problem to expose API methods then so that host languages/programs
> could use them.  In addition, it'd also mean one could create a
> different orch language using a different grammar definition and reuse
> the engine.  This would make Csound a much more generic audio engine
> which I think would be a plus.
>
> As for control events, I'm not too familiar with them from SAOL, but I
> imagine you're referring to something like MIDI controller events.
> blue does this with widgets for instruments to do parameter automation
> by synthesizing instruments just for sending global k-rate signals to
> the instrument that also reads the k-rate signals.  So, if a program
> takes are of managing to create the instruments and variables in the
> instrument code so that there are no variable name clashes, then that
> feature is possible already, but a separate solution may be nice.
>
> Thanks!
> steven
>
>
>
>
>
> On Thu, Feb 5, 2009 at 7:38 PM, Anthony Kozar
>  wrote:
>> 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
> 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