For some reason, I can't update the old ideas page, I only get a  
'server error' message. So I have added a new page, which is now our  
ideas page:

http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new

I have edited in the ideas provided here. Please let me know your  
opinion.

Victor

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Victor -

thanks a lot for your work on this, and to Andrés for the initiative.  
Some ideas/wishes by me. You will judge whether Google's sumer is a  
good place for them:
1. Make Csound able to read lines from an external file and return  
them as a string (freads as complement to fprints).
2. After finishing the new parser, make possible that N strings can be  
in a score line, can be the input for an UDO, and also its output.
3. Let UDOs be in an arbitrary order, so that number 1 can be compiled  
even if it uses number 5.
4. Let UDOs be able to define other UDOs internally (like defun in  
Lisp, or others).

	joachim

Am 11.03.2010 um 08:45 schrieb Victor Lazzarini:

> For some reason, I can't update the old ideas page, I only get a
> 'server error' message. So I have added a new page, which is now our
> ideas page:
>
> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
>
> I have edited in the ideas provided here. Please let me know your
> opinion.
>
> Victor
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> 1. Make Csound able to read lines from an external file and return
> them as a string (freads as complement to fprints).

I agree. I think better handling of strings in general would be a
great improvement.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, specifically, getting rid of any "only one string" limitations
(they're still there, yes?)

On Thu, Mar 11, 2010 at 8:51 AM, Rory Walsh  wrote:
>> 1. Make Csound able to read lines from an external file and return
>> them as a string (freads as complement to fprints).
>
> I agree. I think better handling of strings in general would be a
> great improvement.
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks. I guess your number one is quite feasible out of the GSoC, so  
we should try to it straight away.
The limitation of strings should be removed and this is a good idea I  
had forgotten about.

For 3. we could have a means of declaring UDOs at the top. But I am  
not sure nesting of UDOs is a good
idea, maybe it is but we need to discuss it.

Victor


On 11 Mar 2010, at 13:37, joachim heintz wrote:

> Hi Victor -
>
> thanks a lot for your work on this, and to Andrés for the initiative.
> Some ideas/wishes by me. You will judge whether Google's sumer is a
> good place for them:
> 1. Make Csound able to read lines from an external file and return
> them as a string (freads as complement to fprints).
> 2. After finishing the new parser, make possible that N strings can be
> in a score line, can be the input for an UDO, and also its output.
> 3. Let UDOs be in an arbitrary order, so that number 1 can be compiled
> even if it uses number 5.
> 4. Let UDOs be able to define other UDOs internally (like defun in
> Lisp, or others).
>
> 	joachim
>
> Am 11.03.2010 um 08:45 schrieb Victor Lazzarini:
>
>> For some reason, I can't update the old ideas page, I only get a
>> 'server error' message. So I have added a new page, which is now our
>> ideas page:
>>
>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
>>
>> I have edited in the ideas provided here. Please let me know your
>> opinion.
>>
>> Victor
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Yes, specifically, getting rid of any "only one string" limitations
> (they're still there, yes?)

I have a small suggestion for strings.

For referring to a string named-instrument in quotes in the score, how
about eliminated the need for quotes for p1? For example, instead of
this:

i "RezzyBass" 0 4 0.707 6.07

Do this:

i RezzyBass 0 4 0.707 6.07

I did some tests awhile back, and as far as I could tell, spaces are
not permitted for string-named instruments, thus, it would be a
continuous string that could be easily matched by the parser. Doing
this would improve readability, imho. Not to mention, reduce four key
presses (shift-' x 2) per i-event. :)

Though this now has me thinking. Why not do away with quoting strings
in scores all together, except for occasions where users need to type
in strings that do include spaces or special characters?

i RezzyBass 0 4 0.707 6.07 Space_Verb 0.3 "Wide Chorus" 0.7

Food for thought. And of course, this would depend greatly on the one
string limitation being removed.

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks. I'll be collecting these things to include them tomorrow, the  
last day before final submission.
On 11 Mar 2010, at 16:22, Jacob Joaquin wrote:

>> Yes, specifically, getting rid of any "only one string" limitations
>> (they're still there, yes?)
>
> I have a small suggestion for strings.
>
> For referring to a string named-instrument in quotes in the score, how
> about eliminated the need for quotes for p1? For example, instead of
> this:
>
> i "RezzyBass" 0 4 0.707 6.07
>
> Do this:
>
> i RezzyBass 0 4 0.707 6.07
>
> I did some tests awhile back, and as far as I could tell, spaces are
> not permitted for string-named instruments, thus, it would be a
> continuous string that could be easily matched by the parser. Doing
> this would improve readability, imho. Not to mention, reduce four key
> presses (shift-' x 2) per i-event. :)
>
> Though this now has me thinking. Why not do away with quoting strings
> in scores all together, except for occasions where users need to type
> in strings that do include spaces or special characters?
>
> i RezzyBass 0 4 0.707 6.07 Space_Verb 0.3 "Wide Chorus" 0.7
>
> Food for thought. And of course, this would depend greatly on the one
> string limitation being removed.
>
> Best,
> Jake
> -- 
> The Csound Blog - http://csound.noisepages.com/
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Thanks. I'll be collecting these things to include them tomorrow, the
> last day before final submission.


There's one other issue with named instruments for which I don't think
is possible. Fractional instruments in the score. Such as:

i 1.1 0 4

Periods are not allowed in string-named instruments, so something like
this could be safely implemented without affecting backwards
compatibility. It would be up to, I'm guessing, the parser engine:

i RezzyBass.1 0 4 0.4 100
i "RezzyBass".2 4 4 0.6 200


Sorry to steamroll you guys with this, but this just made me think of
another issue.  How could one specify a fractional string-named
instrument from another instrument? My guess is it would need a new
opcode to convert strings into their number equivalents, but also
allow numbers through as well. Consider this mockup instr with the
mockup opcode instrnum.



instr Turnoff
    i_instr instrnum p4
    turnoff2 i_instr, 4, 0
    turnoff
endin
...
i Turnoff 2 1 RezzyBass.1


instrnum would convert "RezzyBass.1" into 1.1 (assuming that instr was
the first in the orchestra).  Though it would also work for this, as
to remove the need to have two separate Turnoff instruments, one for
string-named and one for numbers:


i Turnoff 2 1 1.1

Going back in the other direction may be useful, too:

instr Foo
    Sname instrstr 1  ; Produces "RezzyBass"
endin



So I'm guessing by now, I've turned all of you off by this.  :)

Best,
Jake
-- 
The Csound Blog - http://csound.noisepages.com/

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am thinking that we should accept that the score language is a language
and implement it in lex/yacc.  Then many of these problems become "easy"
  That was always on my personal list
==John

PS And I ought to document the .csd score generator code

>> Thanks. I'll be collecting these things to include them tomorrow, the
>> last day before final submission.
>
>
> There's one other issue with named instruments for which I don't think
> is possible. Fractional instruments in the score. Such as:
>
> i 1.1 0 4
>
> Periods are not allowed in string-named instruments, so something like
> this could be safely implemented without affecting backwards
> compatibility. It would be up to, I'm guessing, the parser engine:
>
> i RezzyBass.1 0 4 0.4 100
> i "RezzyBass".2 4 4 0.6 200
>
>
> Sorry to steamroll you guys with this, but this just made me think of
> another issue.  How could one specify a fractional string-named
> instrument from another instrument? My guess is it would need a new
> opcode to convert strings into their number equivalents, but also
> allow numbers through as well. Consider this mockup instr with the
> mockup opcode instrnum.
>
>
>
> instr Turnoff
>     i_instr instrnum p4
>     turnoff2 i_instr, 4, 0
>     turnoff
> endin
> ...
> i Turnoff 2 1 RezzyBass.1
>
>
> instrnum would convert "RezzyBass.1" into 1.1 (assuming that instr was
> the first in the orchestra).  Though it would also work for this, as
> to remove the need to have two separate Turnoff instruments, one for
> string-named and one for numbers:
>
>
> i Turnoff 2 1 1.1
>
> Going back in the other direction may be useful, too:
>
> instr Foo
>     Sname instrstr 1  ; Produces "RezzyBass"
> endin
>
>
>
> So I'm guessing by now, I've turned all of you off by this.  :)
>
> Best,
> Jake
> --
> The Csound Blog - http://csound.noisepages.com/
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi,
Google recommends adding some information about complexity and skills
required for the ideas. Here is a shot at that.

1. Engine/system components:

1.1 Dynamic modification of the Csound engine: this involves the
implementation of dynamic loading and unloading of instruments. It
includes a modification of the role of the parser, so that compilation
can happen 1 to many times, with each defintion in ORC potentially
replacing an old one)

Complex. Requires good knowledge of C and Csound.

1.2 Complete revision of opcodes and opcode plugins: this will require
moving deprecated and redundant opcodes to a separate "deprecated"
plugin module and making relevant reference manual annotations.

Medium. Requires good knowledge of C and Csound.

1.3 Finish work on the new parser: this includes new parser
verification, (a?b:c) construction, checking, type inference, etc.; a
work on optimisation of parse tree (including the investigation of
static-single assignment) is also an important aspect of this.

Medium. Requires good knowledge of C, Csound, lex and yak.

1.4 Implementing a functional-language design: with the new parser,
allow usage of all opcodes as functions for arguments to other
opcodes.

Medium. Requires good knowledge of C, Csound, lex and yak.

2. New Processing algorithms and opcodes

2.1. Implement additions/improvements to the streaming phase vocoder
signal system. This should involve: (a) providing a better means of
extracting residuals from sinusoidal tracks; (b) implementing onset
and transient detection / processing; (c) implementing phase locking;
(e) implementing real-imaginary (complex) and amp-phase signal
operations (analysis, conversion, resynthesis,processing); (f)
implementing Constant-Q sliding DFT

Complex. Requires good knowledge of C, Csound and DSP.

2.2  Re-implementation of VST host opcodes used VeSTige headers: this
will enable us to distribute vst4cs and CsoundVST on SourceForge.

Simple. Requires knowledge of C and C++.

2.3 Add DBus opcodes to Csound: DBus is used by at least some
implementations of Jack and is a lightweight, high-performance message
bus.

Medium. Requires knowledge of C, C++ and Csound.

2.4 Removal of power-of-2 restriction for all opcodes: it needs to
investigated whether the integer indexing code used by some opcodes is
strictly needed for performance reasons. It it does not provide a
performance gain, indexing should be made floating-point universally
and the power-of-2 restriction on some opcodes should be removed.

Medium. Requires knowledge of C, C++ and Csound.

3. Parallel operation support

3.1 Finish the auto parallelisation of code: coupled with the work on
the new parser, we should look into completing the auto
parallelisation work which was started last year. This will also
involve the performance measurement of opcodes

Complex. Requires knowledge of C, C++, Csound and good understanding
of parallelization and concurrent processing.

3.2 Investigate the possible adoption of the OpenMP standard: once
this work is completed, we can look into using OpenMP for the
implementation of paralllel code.

Complex. Requires knowledge of C, C++, Csound and good understanding
of parallelization and concurrent processing.

4. Csound code libraries and didatic material

4.1 Develop a library of high-quality instrument definitions: this
involves especially band-limited and physically modeled instruments,
that can be #included in orchestras and interface via the bus and the
signalflowgraph opcodes.

Simple. Requires knowledge of Csound and software synthesis.


Cheers,
Andrés

On Thu, Mar 11, 2010 at 7:45 AM, Victor Lazzarini
 wrote:
> For some reason, I can't update the old ideas page, I only get a
> 'server error' message. So I have added a new page, which is now our
> ideas page:
>
> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
>
> I have edited in the ideas provided here. Please let me know your
> opinion.
>
> Victor
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
htt

Thanks. Here's the new ideas page with the collated information

http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_final

Victor
On 11 Mar 2010, at 18:42, Andres Cabrera wrote:

> Hi,
> Google recommends adding some information about complexity and skills
> required for the ideas. Here is a shot at that.
>
> 1. Engine/system components:
>
> 1.1 Dynamic modification of the Csound engine: this involves the
> implementation of dynamic loading and unloading of instruments. It
> includes a modification of the role of the parser, so that compilation
> can happen 1 to many times, with each defintion in ORC potentially
> replacing an old one)
>
> Complex. Requires good knowledge of C and Csound.
>
> 1.2 Complete revision of opcodes and opcode plugins: this will require
> moving deprecated and redundant opcodes to a separate "deprecated"
> plugin module and making relevant reference manual annotations.
>
> Medium. Requires good knowledge of C and Csound.
>
> 1.3 Finish work on the new parser: this includes new parser
> verification, (a?b:c) construction, checking, type inference, etc.; a
> work on optimisation of parse tree (including the investigation of
> static-single assignment) is also an important aspect of this.
>
> Medium. Requires good knowledge of C, Csound, lex and yak.
>
> 1.4 Implementing a functional-language design: with the new parser,
> allow usage of all opcodes as functions for arguments to other
> opcodes.
>
> Medium. Requires good knowledge of C, Csound, lex and yak.
>
> 2. New Processing algorithms and opcodes
>
> 2.1. Implement additions/improvements to the streaming phase vocoder
> signal system. This should involve: (a) providing a better means of
> extracting residuals from sinusoidal tracks; (b) implementing onset
> and transient detection / processing; (c) implementing phase locking;
> (e) implementing real-imaginary (complex) and amp-phase signal
> operations (analysis, conversion, resynthesis,processing); (f)
> implementing Constant-Q sliding DFT
>
> Complex. Requires good knowledge of C, Csound and DSP.
>
> 2.2  Re-implementation of VST host opcodes used VeSTige headers: this
> will enable us to distribute vst4cs and CsoundVST on SourceForge.
>
> Simple. Requires knowledge of C and C++.
>
> 2.3 Add DBus opcodes to Csound: DBus is used by at least some
> implementations of Jack and is a lightweight, high-performance message
> bus.
>
> Medium. Requires knowledge of C, C++ and Csound.
>
> 2.4 Removal of power-of-2 restriction for all opcodes: it needs to
> investigated whether the integer indexing code used by some opcodes is
> strictly needed for performance reasons. It it does not provide a
> performance gain, indexing should be made floating-point universally
> and the power-of-2 restriction on some opcodes should be removed.
>
> Medium. Requires knowledge of C, C++ and Csound.
>
> 3. Parallel operation support
>
> 3.1 Finish the auto parallelisation of code: coupled with the work on
> the new parser, we should look into completing the auto
> parallelisation work which was started last year. This will also
> involve the performance measurement of opcodes
>
> Complex. Requires knowledge of C, C++, Csound and good understanding
> of parallelization and concurrent processing.
>
> 3.2 Investigate the possible adoption of the OpenMP standard: once
> this work is completed, we can look into using OpenMP for the
> implementation of paralllel code.
>
> Complex. Requires knowledge of C, C++, Csound and good understanding
> of parallelization and concurrent processing.
>
> 4. Csound code libraries and didatic material
>
> 4.1 Develop a library of high-quality instrument definitions: this
> involves especially band-limited and physically modeled instruments,
> that can be #included in orchestras and interface via the bus and the
> signalflowgraph opcodes.
>
> Simple. Requires knowledge of Csound and software synthesis.
>
>
> Cheers,
> Andrés
>
> On Thu, Mar 11, 2010 at 7:45 AM, Victor Lazzarini
>  wrote:
>> For some reason, I can't update the old ideas page, I only get a
>> 'server error' message. So I have added a new page, which is now our
>> ideas page:
>>
>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
>>
>> I have edited in the ideas provided here. Please let me know your
>> opinion.
>>
>> Victor
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Victor Lazzarini wrote:
> 
> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
> I have edited in the ideas provided here. Please let me know your  
> opinion.
> Victor
> 

Page is interesting.  What are signalflowopcodes, if I might ask?

-- 
View this message in context: http://old.nabble.com/new-ideas-page-tp27860294p27889091.html
Sent from the Csound - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

They are documented in the current manual.

Regards,
Mike

On Sat, Mar 13, 2010 at 11:46 AM, jhearon  wrote:
>
>
>
> Victor Lazzarini wrote:
>>
>> http://socghop.appspot.com/document/show/user/csound_2010/csound_2010_ideas_new
>> I have edited in the ideas provided here. Please let me know your
>> opinion.
>> Victor
>>
>
> Page is interesting.  What are signalflowopcodes, if I might ask?
>
> --
> View this message in context: http://old.nabble.com/new-ideas-page-tp27860294p27889091.html
> Sent from the Csound - Dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net