Very interesting questions!

I personally am not terribly interested in a new "engine" for Csound.

It seems to me that it is good to continue to refine and extend the current 
engine, with or without parser, for the sake of the body of work invested in 
Csound -- not only the Csound code, but also instrument definitions, pieces 
that can be studied, books, and so on and so on. Arguably, the richest body 
of computer music based on a particular software sound synthesis system.

It also seems to me that it is good to invent something quite new, if 
possible, that does not even share the Csound languages or concepts.

I am afraid putting a lot of work into the internals of Csound will not 
provide as much "bang for the hour" as adding new opcodes, refining the code 
(nobody has used a profiler on it, or have they?), and of course actually 
making music.

Or, as much "bang" as writing a new synthesis system from scratch. I know 
from experience both with computer music, and with trading systems, that 
writing a new system from scratch is generally much easier than rewriting an 
existing system.

If anyone is interested, I have been experimenting with new synthesis 
systems for years. I would write a new system as a framework for an existing 
language, rather than creating a new language designed for music. That way, 
nobody has to write any code except for making sounds or scores. At the 
moment, I am not quite sure just what language.

I have written working prototypes of such systems in Java, C++/Tcl, 
C++/Python, C++/Lua, and C++ with embedded compiler (this last one based on 
SAOL). OCaml, Lisp, Lua, Python, Java, C#, and F# would all work. So, for 
that matter, would embedding a C or C++ compiler right into the synthesis 
system. At the moment, I think writing a new system from scratch for Steel 
Bank Common Lisp would be a good approach, or writing a new system from 
scratch in C++ with Lua wrappers generated by SWIG. OCaml is very well 
suited to the task, but not that many musicians know it.

Whatever language is chosen, it needs to be able to run routines written in 
C or C++, and it needs to have either a native compiler, or a just in time 
compiler. All the languages I mentioned meet this criterion.

At the moment, the silencevst project on SourceForge contains a working 
prototype of such a system written in C++ that is programmable in Lua. It 
only builds on Windows right now. The basic framework appears to be roughly 
as efficient as Csound, but it is parallelizable (I even have parallel task 
code written for Intel Threading Building Blocks, but it is stubbed out 
right now because there doesn't seem to be a MinGW TBB).

A C/C++ system could be created similar to CLAM or the Create Signal Library 
or by extending the STK. The required libraries, and the runtime library and 
other support libraries required by the C++ compiler, could be packaged as 
an integral part of the system, which would simply shell out to run the 
compiler with a generated command, then load and run a shared library that 
would be the piece. I had this working with SAOL and it worked very well. It 
was certainly the most powerful of all the prototype systems I made. But 
rather than implementing SAOL, I think it would be even more powerful to 
simply create a DSP graph framework for the STK and write STK-type wrappers 
for a bunch of other computer music goodies, then assume that you will write 
pieces in C++ and the synthesis system will compile them for you without you 
having to create a makefile. It would be easy to make such a system 
parallelizable.

The size of all the libraries, C++ compiler, etc. is now roughly the same as 
the size of the installer for Csound or Pure Data.

Regards,
Mike

----- Original Message ----- 
From: "Steven Yi" 
To: "Developer discussions" 
Sent: Sunday, September 09, 2007 9:15 PM
Subject: [Cs-dev] Engine Changes,or Csound 6 (was Re: [Csnd] feature 
request: multiple strings in"i" statements)


> Hi Anthony,
>
> I wasn't aware of the previous conversation but searched my mail box
> and found it; it was right around when I was leaving Warsaw so
> probably was the furthest thing from my mind.  (The nabble thread is
> here: 
> http://www.nabble.com/Re%3A-more-than-one-string-in-an-i-statement-tf3655313.html#a10220997)
>
> The variant type is an ideal solution but I am close to certain it
> would require *much* more work than what is mentioned in that thread.
> The code in that thread does not take into account that the lookup as
> it is now is done per-opcode, not per-instrument.  If we want to do
> away with the SSTRCOD and use a union, then we would have to check the
> type of the union, then check the type of the of the value it is being
> assigned to per expression or opcode arg value.  Currently, opcodes
> themselves check for SSTRCOD then get the strarg value.  Ideally,
> opcodes would just have char* or MYFLT* or whatever they are
> expecting, and the parser itself would hook together correctly and do
> type checking there.  If we introduce the variant type but don't do
> the changes to opcodes, we're back to using some kind of magic
> variable so that the opcode can know its MYFLT * is signifying a
> string.
>
> At this point, I'm more and more interested in re-engineering the
> engine altogether.   There are a number of STRUCT's that could be
> lightened up, memory allocation of instrument instances could change
> from the way it pre-allocates a giant block of memory with indexes to
> one where it is allocating each part individually (not as efficient
> but required for runtime changes to instruments), the maintaining of
> variable names to memory addresses (that is all erased currently after
> parse time, another factor in disallowing runtime modification of
> instruments), etc.  There are also some variables exposed like
> curevtblk which opcodes use that makes it impossible to do multi-core
> or cluster computation. (There is a related variable that has the
> active instrtxt or something like that that goto uses (and thus
> if-else and all branching variants) use that also makes
> multi-core/cluster impossible).
>
> There are a lot of these types of things that are not small changes.
> What does everyone think of starting a new Csound6 branch that will go
> ahead and make some pretty big changes and making Csound5 a stable
> branch? I think then small changes like new opcodes could go into
> Csound5 and perhaps doing the hack suggestion for multiple strings per
> score node.  We could outline large scale changes for Csound6 and then
> branch that off and start to really aim for that.  If we can outline
> the exact changes we want, it should be easy then to target where
> we'll go (seems now we're in a bit of a gray area of figuring out
> where to go now) and should make it easier for outside developers to
> see where we all want to take this and perhaps participate.  Having
> the unstable Csound6 branch (or even just making a new repository in
> CVS like csound5 is) would also make sure we safely do work there and
> not interfere with Csound5 and OLPC and other projects using that.
>
> Thoughts?
> steven
>
>
>
> On 9/9/07, Anthony Kozar  wrote:
>> Just a note:  I believe that this was discussed a couple of months ago 
>> and
>> Michael Gogins already suggested a good solution.  Of course, this 
>> requires
>> modifying the EVTBLK struct.  I pointed out that modifying EVTBLK will 
>> break
>> API compatibility, and I think we decided to put off this change until a
>> time came that we were ready to increase the API major version number
>> (presumably because there are other changes to the API that we want to 
>> make
>> as well).
>>
>> Anthony Kozar
>> anthonykozar AT sbcglobal DOT net
>> http://anthonykozar.net/
>>
>> Steven Yi wrote on 9/9/07 12:53 AM:
>>
>> > Hi All,
>> >
>> > I've taken a preliminary look today and it's a bit complicated to find
>> > a solution considering the way opcodes are all hooked up together as
>> > well as how the magic variable SSTRCOD is used.  (The use of the
>> > SSTRCOD is a bit arbitrary in the first place and could in a very
>> > remote possibility cause an issue if someone were to use the value.)
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Mike Coleman wrote:
> I've been looking at csound and its alternatives (supercollider and
> nyquist seem to be the most viable) with a goal of both making music
> and applying my programming skills to an open source synthesis
> project.  I've been following this conversation with interest, as it
> touches on many of the topics I've been thinking about myself.

I haven't looked at anything else because Csound's general 
approach fits what I want.  Bear that in mind as I comment 
below.

> First off, I really like csound.  I first heard synthesized music when
> I was a kid in the early 70s, and I never dreamed that I'd actually be
> able to use a system very like the system that many of those pioneers
> used to create those fabulous sounds.  There's a real sense of history
> and continuity, and it's wonderful.
> 
> But, now in 2007, the ORC and SCO languages are, well, relics.  You
> can almost see the punch cards in your hands as you look at them.  For
> someone with a programming background, they just seem completely
> lacking by modern standards.  And for novice programmers--meaning just
> about everyone coming from the music side--they must be fairly
> impenetrable.  It pains me to think of musicians getting together in
> study groups to figure out things like how to hack up a portamento
> mechanism for an instrument, or having to trudge through chapters of
> the csound book devoted to needless mysteries.

I wouldn't expect musicians to have to deal with the files, 
at least not at first.  The ideal is to have sequencer-like 
interfaces for scores and pluggable libraries too build 
orchestras.  If you're going to hack around with the text 
files there's a certain unavoidable complexity.  The 
existing formats are inherently simple which might make them 
easier for non-programmers to get to grips with.

> The model of i-, k-, and a-rate variables was quite confusing for me.
> The underlying interface that they abstract actually seems more
> straightforward (initialize at the beginning, then every k period push
> some control parameters in and get one frame of audio data out).  [cf
> generators in Python 2.5]

How do you propose making this clearer?  Certainly the 
different variable types have to be there.

> I know that there are tools to generate SCO files (and maybe some
> ORC?) from other sources, but I think that there are some problems
> that prevent this from really being a suitable solution.  A principle
> one for me is the "portamento problem": Roughly, I want to be able to
> control the parameters (frequency, for example) of a "note" while it's
> playing, from the "score" file, in a natural way and without having to
> specially prepare the instrument.  As far as I can tell, this simply
> isn't possible currently in cscore.

The problem as I see it is one of encapsulation.  There 
should be a "portamento" opcode that you can add to your 
instruments to get them working right.  One obvious way to 
do that with a more advanced language would be through 
inheritance.  Have an "Instrument" class for things 
controlled by pitch and loudness and a "Portamento" mixin.

The nearest I've got now is to have a macro to handle the 
envelopes and the like and feed it a UDO that's controlled 
by pitch, timbre, velocity, etc.  The current orchestra 
language isn't fully pluggable for this.  One problem is 
that I need to pre-allocate zak channels for each instrument 
I want to use effects with.  Another is that, I think, you 
have to declare global variables at the top so you can't 
stitch modules together with includes.

Another think I don't like is that MIDI and GUI code has to 
be in the orchestra files.

> The current regime requires csound to support its own internal
> programming language.  It seems like it would be much better to
> offload that effort by using an existing language (that is already
> being maintained by others elsewhere).  I'd choose Python, because I
> like it and because it is designed and suitable for novice
> programmers, but there are several other languages that would work.
> With the right interfaces, perhaps many languages could be used
> simultaneously, and I would prefer this more catholic approach.

I'm a Python fan but I don't think it's really applicable 
here.  What would a Python orchestra look like?  Would you 
have to run a Python interpreter at k-rate?  I like the 
general idea of signal flow.  I think it's a valid situation 
to use a domain specific language.  I'm not at all clear 
what that language would look like so if you have any ideas 
I'd like to see them.

Most instruments are not that complicated.  We don't need a 
very high level language to build them.  What we need is a 
good set of opcodes with an easy way to wire them together 
(not far from what we have now).

> It's less clear to me how score files should work.  On the one hand,
> it's easy to see them as "data", similar to the current SCO files, or
> HTML, etc.  On the other hand, there are many kinds of things I'd like
> to do that'd be more "programmatic".  Without some programmability,
> one immediately runs across the problem of wanting to repeat a
> pattern, perhaps with small variations, which a pure data
> representation will not handle.  The best thought I have so far is
> that probably both approaches should be supported--a pure data
> representation and a good programmatic interface.

I don't think there's much you can do with score files. 
There are all kinds of other approaches you can use 
pre-processors for.  It's a great dumb format for a high 
level language to spit out.  (And if you write them by hand, 
macros help.)

> If I was going to attempt this myself, I'd be inclined to pretty much
> rip the head off of csound, keep the fabulously useful set of opcodes,
> perhaps clean up the opcode interface, and redo the outer engine,
> probably in Python plus C or C++, and maybe even try to see if Numpy
> (Python numeric package) could help.

I agree with keeping the opcode library, although that's 
also in need of some weeding.

> With proper design, perhaps you could get some parallelism almost for
> free.  It'd be very nice to be able to run multiple processes on a
> multicore box or on a pile of PCs.  (I'm not a fan of threads.)

It's about time we got easy parallelism.

> A primary goal of doing this would be to make it easier to use and
> extend csound.  In the end, I suspect most of us want to spend our
> limited time on the music end, rather than futzing around with the
> technical details.
> 
> I have more thoughts, but that's enough for one post.  I don't mean
> this to sound presumptuous--please think of it as a set of ideas from
> a "focus group" session with one of your fans.

It looks like some people have clear ideas on how to improve 
the engine.  Maybe you could set up a wiki or something and 
we can get ideas on what a next generation score language 
should look like.


                 Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Graham Breed wrote:
.
.
> 
> The problem as I see it is one of encapsulation.  There 
> should be a "portamento" opcode that you can add to your 
> instruments to get them working right.  One obvious way to 
> do that with a more advanced language would be through 
> inheritance.  Have an "Instrument" class for things 
> controlled by pitch and loudness and a "Portamento" mixin.
> 

It depends on just what compromises you are prepared to accept with 
respect to portamento timing. If you are happy to have only 
retrospective portamento (i.e. only from the "previous pitch") then some 
form of encapsulation is possible, as one can cache the previous pitch 
in order to ramp from it to the new one. However, natural real-life 
portamento (i.e. what players like me do) does not work this way. We 
know what note we are about to play, and can therefore ramp to it during 
the ~current~ note. Clearly, this requires knowing the future. Only a 
score-based system which provides that information can do this. Whether 
it is Csound, PD, SC or whatever. I discuss all this and more in my 
chapter in the Csound book. In short: it applies to more than just 
portamento. It applies in principle to all instrument parameters.

Csound is (IMO) designed to impose as few compromises as possible. The 
price of being able to make authentic portamento that accurately 
replicates what real players do, is some sort of mechanism that can tell 
the instrument what the next note is going to be. The Csound score "np~" 
notation does just this. It addds some complexity, but surely not that 
much in the Grand Scheme of Things. Any real time performance system 
will have to support some similar mechanism, and I am most curious to 
know how such a system would do it. MIDI itself has the same problem, as 
does any comparable event-based system. I somehow doubt if any 
instrument exists or will exist that is prescient enough to predict what 
your next note with be (and, as importantly, ~when~ it will be), when 
all you are doing is holding a key down!



Richard Dobson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Mike Coleman wrote:
> On 9/12/07, Graham Breed  wrote:
> 
>>I wouldn't expect musicians to have to deal with the files,
>>at least not at first.  The ideal is to have sequencer-like
>>interfaces for scores and pluggable libraries too build
>>orchestras.  If you're going to hack around with the text
>>files there's a certain unavoidable complexity.  The
>>existing formats are inherently simple which might make them
>>easier for non-programmers to get to grips with.
> 
> Sure.  I'm very comfortable with text files to begin with, so this is
> the interface that I'm most interested in.  Of course, for score files
> at least, it would be possible to write in a "higher-level" score
> language that gets translated down to csound score files.  The primary
> objection to this is that you are limited to what SCO/ORC is capable
> of (thus the portamento problem).

I'm working backwards ... I think I saw another message 
where you explained this portamento problem.  What you want 
is an opcode that tells you what the next note's going to 
be.  Not a new orchestra language.

It's possible to get the last note in an instrument by 
reading a variable you neglected to initialize.  I don't 
know if this works from a UDO.  Ideally it would, so you can 
write

kpitch  portamento  p3, p5

or whatever.  Would that solve the problem?

One problem is that you can't import somebody else's 
instrument and hot-wire it to have portamento without 
changing their source code.  But if the meat of an 
instrument were packaged as a UDO instead then you could do it.

> I guess part of what I'm asking here is whether there isn't some
> alternative that is in general much simpler.  ORC especially feels
> fairly complex, to me.

I don't think so.  ORC is about as simple as possible for 
the problem domain.  Python is much more complex.

>>>The model of i-, k-, and a-rate variables was quite confusing for me.
>>>The underlying interface that they abstract actually seems more
>>>straightforward (initialize at the beginning, then every k period push
>>>some control parameters in and get one frame of audio data out).  [cf
>>>generators in Python 2.5]
>>
>>How do you propose making this clearer?  Certainly the
>>different variable types have to be there.
> 
> 
> 
> Just spitballing, imagine something like this
> 
> class my_sin_instr(cs.Instrument):
>     freq = 0
> 
>     def next(self):
>         ... use freq here...
>         return one_audio_frame           # in some efficient C or Numpy form
> 
> 
> The calling code would be doing something like this
> 
>     msi = my_sin_instr()
> 
> at "init" time, and then
> 
>     msi.freq = 440
>     out = msi.next()
> 
> to control and generate one k step with audio data.   Obviously this
> is very sketchy, but I hope the general idea comes across.  Basically,
> we're doing the same thing, but in a traditional programming language.
>  In my opinion this seems much easier to follow.

You're welcome to that opinion .  How does it compare 
with the existing API?

>>The problem as I see it is one of encapsulation.  There
>>should be a "portamento" opcode that you can add to your
>>instruments to get them working right.  One obvious way to
>>do that with a more advanced language would be through
>>inheritance.  Have an "Instrument" class for things
>>controlled by pitch and loudness and a "Portamento" mixin.
> 
> If this could be done with an existing language as the foundation, I
> think it'd be great.  It just seems like maintaining one's own private
> programming is a lot of work for very little benefit.

There are projects out there developing synthesizer 
libraries for Java and other languages.  I don't know about 
Python.

>>Another think I don't like is that MIDI and GUI code has to
>>be in the orchestra files.
> 
> One nice thing about going with (say) Python is that you get packages
> for things like GUI, graphing, perhaps some audio/MIDI bindings,
> parallelization, etc., for free.  And someone else would be
> maintaining them.

I think you can use those anyway with the existing orchestra 
files and Python API.  Except for parallelization which 
Python is as lousy at as Csound.

>>I'm a Python fan but I don't think it's really applicable
>>here.  What would a Python orchestra look like?  Would you
>>have to run a Python interpreter at k-rate?  I like the
>>general idea of signal flow.
> 
> Yes, I pretty much have in mind running Python at k-rate.  On current
> commodity hardware it does maybe a million plus trivial loops per
> second.  There would have to be a proper division between performance-
> and not-critical parts, the former being implemented as C (or
> whatever) modules, but this seems plausible to me, even for real-time.

Running python is going to require more overhead than a 
dedicated, compiled-down orchestra language.  Hence it'll 
limit the polyphony, reverb depth and the like.  I think 
it'll be problematic for a long time yet.

> As for the signal-flow model, the model could be whatever works.  In
> fact, since the model wouldn't be welded to the programming language,
> there would be opportunities to experiment with multiple models.

The point is, most instruments are based on a wiring 
metaphor.  You take a black box, wire it to another black 
box, and so on.  It's what people are familiar with from 
modular synths.  And it's very powerful because all the 
complexity's hidden in the black boxes (opcodes) which you 
can implement in a number of languages.  And audio's all 
about low-dimensional signals.  In the orchestra, it comes 
down to a lot of lines like

outputs  opcode  inputs

I can't see how that could be simpler.  The convention is to 
align it all in three columns, which gives the punch card 
impression, but that also makes it clear to read.  The 
equivalent in Python would be

outputs = opcode(inputs)

More syntactic sugar!  And most of the time this is all 
you'd be writing.  The advantages with Python would be that 
you can treat all the inputs and outputs as a chunk (maybe 
if one opcode takes inputs that exactly match another 
opcode's outputs) and you don't need to specify the rate in 
the variable name.  I don't know if the latter's so easy to 
achieve without changing the opcodes.  How do you differentiate

kpitch  portamento

from

apitch  portamento

for example?

>>Most instruments are not that complicated.  We don't need a
>>very high level language to build them.  What we need is a
>>good set of opcodes with an easy way to wire them together
>>(not far from what we have now).
> 
> 
> I guess I'm wondering whether csound instruments tend to be relatively
> short because longer instruments are unneeded or because writing them
> in the existing language is just too painful to face.  I think it's
> worth at least asking whether there isn't something else that would be
> significantly better.

Usually people who don't like the orchestra language want a 
graphical system instead.  Well, I know something about this 
because I used to use Kyma.  The thing is that a wiring 
diagram can get really difficult to take in when it reaches 
a certain complexity.  And it may boil down to, say, 10 
lines of Csound orchestra code?  It can still be difficult 
to take in but I think that's the inherent complexity 
involved in audio processing.  And the solution is good opcodes.

The other thing is that we already have a pretty good 
modular system with UDOs.  That's difficult to do graphically.

All that you can do with signal flow diagrams can be done with

inputs  opcode  outputs

in a Csound score.  In addition to that you have if 
statements and gotos!  Compared to a high level language, 
that looks primitive.  But it's all you need.  It means you 
can do all kinds of magic that wouldn't be possible in a 
purely graphical system.  And for clever stuff you can 
always code your own opcodes.  Python-style control 
structures would require Python-style indentation, which 
breaks the 3 column format.


              Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Mike Coleman wrote:
> On 9/13/07, Graham Breed  wrote:
> 
>>kpitch  portamento  p3, p5
>>
>>or whatever.  Would that solve the problem?
> 
[You'd probably want at least one other parameter for 
"portamento time" of course.]
> 
> Hmm.  Well perhaps, albeit in a fairly awkward way.  I'm really
> looking for something that can manipulate all kinds of controls, not
> just frequency.

And opcodes can do that!  What do you envision that can't be 
written as an opcode?  What's awkward?  It's only one line.

>>I don't think so.  ORC is about as simple as possible for
>>the problem domain.  Python is much more complex.
> 
> Ah, well, this is a fundamental difference in philosophy.  So maybe I
> should ask whether there is not something significantly simpler than
> the current regime for someone who thinks that Python is a very simple
> language.  :-)

Lua's been mentioned in the thread, I think.  Are you saying 
Python's simpler than Lua?

Philosophically, surely instrument definitions will always 
be simpler in a domain specific language than one where you 
have to use a general class syntax.

>>You're welcome to that opinion .  How does it compare
>>with the existing API?
> 
> I'm not sure what you mean by the existing API...

The Csound Python API.  I don't know it myself.

>>The advantages with Python would be that
>>you can treat all the inputs and outputs as a chunk (maybe
>>if one opcode takes inputs that exactly match another
>>opcode's outputs) and you don't need to specify the rate in
>>the variable name.  I don't know if the latter's so easy to
>>achieve without changing the opcodes.  How do you differentiate
>>
>>kpitch  portamento
>>
>>from
>>
>>apitch  portamento
> 
> One could imagine many ways, but perhaps the easiest is that a single
> value means "k rate", while an array of values would mean "a rate".

Yes, but how would the "portamento" function know what to 
return?  You'd have to declare the type of the result 
somehow.  In the current language that's done by the first 
letter of the variable name.  Nothing similar will work in 
Python because of the dynamic typing.  The pitch will be 
assigned to whatever type "portamento" returns.  How do you 
tell it that type, while preserving the existing opcodes?

>>Usually people who don't like the orchestra language want a
>>graphical system instead.
> 
> I can imagine so, but that's not my wish.  In fact, I'm pretty much
> completely in the opposite direction.  I'd like to have an input
> language more along the lines of LilyPond's input language, but
> cleaner.  (Well, I guess this would be the score language.  The
> instrument language might be Python.)

I haven't got round to looking at LilyPond yet.  It's geared 
for staff notation though, isn't it?  Not equivalent to 
Csound's scores.


                       Graham

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I've been only speed-browsing this thread so please forgive if I'm a  
bit off-topic.
For me, the csound orchestra/score is remarkably resilient and  
adaptable.
Why, one can think of a (bank of) reverb UGs (or even OUTs) as the  
continuous source.
The resonator/control model is very flexible and at the basis of the  
lang/synth divisions of more recent rethinks, such as Supercollider.

For me, the important issues are those that resolve around UG  
development and embed- and extens-ability, and the interpreter/ 
compiler qualities of a scripting language which make it a useful  
interface to csound. Related to this is to what extent the scripter  
allows one to interface to the rest of the computation world, which  
itself is related to the number and type of other current projects  
which one can interface through the same scripting interface.

For me, 'tool development parallelism' is as important as hardware  
parallelism and is one reason why I use python. See my ICAD paper  
downloadable from sonipy.sourceforg.net, which outlines just a  
beginning. It doesn't reference csound yet but will soon. An then  
there's PyTables and the list goes on.

  Whilst I might enjoy the qualities of individual interpretive  
languages for metamusical conceptualising leading to score/sound  
generation, a balance needs to be found between
(a) spending time maintaining an interpreter (which I spent many  
years doing with APL and Forth for example, not forgetting Lisp,  
SClang),
(b) building scripting interfaces to major engines, like csound, with  
new expressive tools, and
(c) generating sound as effortlessly as possible.

None of this is to discount importance of the affordance which public  
domain gives to individuals the ability to explore (b)  to their  
hearts content.
But it is a different impetus to the desire of the developers of a  
core technology (such as csound) to make it available to a wide  
variety of users.
Afterall, musical composition itself is being constantly reinvented,  
and this has meant ways of interacting with data/processes outside  
the computational world itself.

my 0.02 euro's worth  :-)

David

On 20/09/2007, at 8:40 AM, Mike Coleman wrote:

> On 9/14/07, Mike Coleman  wrote:
>> On 9/13/07, Graham Breed  wrote:
>>> Lua's been mentioned in the thread, I think.  Are you saying
>>> Python's simpler than Lua?
>>
>> I don't know much about Lua, so I'm inclined to think Python'd be
>> slightly simpler, but they are essentially equivalent as compared to
>> the ORC language.
>

_________________________________________________
experimental polymedia:	www.avatar.com.au
Sonic Communications Research Group,
University of Canberra:	 creative.canberra.edu.au/scrg
vip=Verbal Interactivity Project




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net