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

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.


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


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

I'm not sure what you mean by the existing API...


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


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

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