[Bluemusic-devel] [Fwd: Re: Some feature requests to help me write LilyPond aware instruments]
Brought to you by:
kunstmusik
From: Bernard H. <be...@ph...> - 2008-04-03 05:52:49
|
Sorry this was meant to go to the list the first time! -------- Forwarded Message -------- > From: Bernard Hurley <be...@ph...> > Reply-To: be...@ph... > To: Steven Yi <ste...@gm...> > 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 <be...@ph...> 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 > > > > > > > > |