[Fwd: Re: Some feature requests to help me write LilyPond aware instruments]

> From: Bernard Hurley <bernard@...>
> Reply-To: bernard@...
> To: Steven Yi <stevenyi@...>
> Subject: Re: [Bluemusic-devel] Some feature requests to help me write
> LilyPond aware instruments
> Date: Thu, 03 Apr 2008 06:40:41 +0100
>
> Yes this looks good! I will have a go at it. I've only used blue for a
> month or so so that I'm not used to what it can/can't do yet. I guess if
> I wanted to do some algorithmic composition in Csound I would have to
> revert to something like my previous ideas - but otoh it looks like blue
> is better for that too!
>
> On Wed, 2008-04-02 at 22:17 -0700, Steven Yi wrote:
> > Interesting, well, I certainly don't much like #defines or #ifdefs and
> > would prefer using csound code for type safety, but either way is
> > fine.
> >
> > I am thinking that for your other email request regarding <p3orig> or
> > something like that, and for this too, you could maybe not even use
> > csound to write the code, but rather, use blue to do it.  What I was
> > thinking was creating a python noteprocessor and placing it on the
> > root timeline (right-click the root object in the polyobject bar).
> > When a note processor is run on the root timeline, it basically runs
> > on all generated notes.  You get access to the notes as blue Note
> > objects, and you can iterate through them as a list, using code like:
> >
> > for note in noteList:
> >   print note.pfield(2)
> >
> > That way, you'd get a lot of things to happen.  One, you'd cleanly
> > separate your csound code and your Lilypond code, as your instruments
> > wouldn't have any lilypond code.  Two, you'd get to do all your work
> > in python, which you're already doing with the mixed csound code.
> > Three, you'd get access to the notes after blue is finished processing
> > them but before Csound applies anything due to t- statement, basically
> > getting the values in the CSD and not what Csound does with it after
> > the CSD.
> >
> > I think doing this might actually be the simplest solution.  Thoughts?
> >
> > steven
> >
> >
> > On Wed, Apr 2, 2008 at 9:58 PM, Bernard Hurley <bernard@...> wrote:
> > > Hi Steve,
> > >
> > >  Thanks! Why use macros when I could use UDO's? Well I don't think I
> > >  could use UDO's. Essentially I want two radically different versions of
> > >  Lily-aware instruments with code looking something like:
> > >
> > >  #ifdef  LilyWriter
> > >  -- code that writes stuff to a python list that LilyWriter then uses --
> > >  #else
> > >  -- code that actually produces sound ---
> > >  #end
> > >
> > >  This way I can change the behaviour of these instruments simply by
> > >  toggling the activation of the LilyWriter instrument. Also the
> > >  instruments could be used as is in Blue projects that did not contain
> > >  LilyWriter.
> > >
> > >  There _are_ other ways of achieving this, but all of them seem quite
> > >  messy to me and are not as efficient at run time. Also the #ifdef
> > >  construct makes it visually clear which code goes with which version of
> > >  the instrument.
> > >
> > >  Regards,
> > >
> > >  Bernard
> > >
> > >
> > >
> > >  On Wed, 2008-04-02 at 21:18 -0700, Steven Yi wrote:
> > >  > Hi Bernard,
> > >  >
> > >  > Thanks for mentioning the bug with the pre block processing (number
> > >  > 1).  I took a look and have fixed the processing.  It is now passing
> > >  > the lines with original formatting (it was previously trimming all
> > >  > lines).  This is in CVS and I have placed  a build at:
> > >  >
> > >  > http://www.kunstmusik.com/blue_0.123.0_beta_installer.jar
> > >  > http://www.kunstmusik.com/blue_0.123.0_beta.zip
> > >  >
> > >  > As for 2, I'm not sure I could get to anything like that anytime soon.
> > >  >
> > >  > Number 3, well, I could probably add something like a top.  As a side
> > >  > note, what I'm wondering is, why use macros when you could use UDO's?
> > >  >
> > >  > Thanks,
> > >  > steven
> > >
> > >
> >