On 9/12/07, Graham Breed <gbreed@gmail.com> 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 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.


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


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


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

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.


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

Mike

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