Some feature requests to help me write LilyPond aware instruments

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Some feature requests to help me write LilyPond aware instruments

Bernard Hurley
Hi All,

First I will explain what I am doing. I am into music for electronic +
live instruments. The basic idea is that some instruments could
"represent" live instruments and could produce actual sound while I am
composing, but could go into "LilyPond" mode, turning off their sound
output but producing a LilyPond score instead when I finally produce my
audio output.

I am developing a "LilyWriter" instrument:

A] In it's global ORC tab it would contain stuff like:

;[pre]{
#define LilyWriter #<INSTR_ID>#
        pyinit
        pyruni {{
def hello():
\t print "hello - let's see if this works!!!"
#------- lots of python code goes here -------
}}
;}

"What's the '\t' for?" I hear you ask. Well, if it is not there, the
python ends in the CSD file as:

def hello():
print "hello - let's see if this works!!!"
-- etc --

Python doesn't like this at all!! This leads to my first request:

        Request 1: would it be possible for blue NOT to reformat the
        code in an instrument's global ORC tab? - At least inside a
        Csound string of the form {{ ---- }}

If you actually type this code into blue you will find that the Python
gets highlighted as if it were Csound. Leading to:

        Request 2: Could syntax highlighting be turned off inside such
        strings?

B] The "LilyWriter" global SCO tab contains:

i <INSTR_ID> 0 <TOTAL_DUR>

Now other instruments can be made LilyPond aware, just by using
constructions like:

#ifdef $LilyWriter
----- some stuff
#endif

This can be done inside the instrument itself or in the global ORC tab
of the instrument. The upshot of this is that if the "LilyWriter"
instrument is included in the orchestra, then it can write the LilyPond
score. I won't go into details but I it is starting to work! If it is
not included then no score is produced and maybe the Lily-aware
instruments can produce sound. All this requires is ticking one box in
blue - quite cool!

However there is one place where this trick doesn't work - this is in
the Global orchestra for the whole project. Code typed into the "Global
Orchestra" box on the "global" tab for the project appears in the CSD
file BEFORE code tagged with [pre] in an instrument - so it is not
possible to use the macro $LilyWriter at this point. This leads to my
third request:

        Request 3: Could [pre] be implemented so that it placed code
        BEFORE the project's global orchestra code? On second thought
        this might break some people's blue projects - so maybe a new
        tag [top] could be implemented.

Requests 1 and 2 are not that urgent - being a matter of an ugly hack
and eye candy respectively, but it would be REALLY USEFUL to me if 3,
could be implemented.

Thanks for reading all this!

Regards,

Bernard



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluemusic-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley
Hi All,

Sorry to be a pain, but I have another request! I have just began thinking of the effect of time warping on what I am doing. I have been using the values of p2 and p3 in my code generating Lilypond, but I have realised that what I really want is the valued before any Csound time-warping. So far I haven't found out how to get at these in Csound itself - although apparently they are sent to the instrument. However Blue obviously knows what these values are, so another possibility would be to have blue variables <p2orig> and <p3orig> that I could use as p-fields. Note that it is the values after blue note processing that I need so I can't simply duplicate p2 and p3!

Thanks

Bernard

ps. Did anyone spot the typo in my original missive?

Bernard Hurley wrote
Hi All,

First I will explain what I am doing. I am into music for electronic +
live instruments. The basic idea is that some instruments could
"represent" live instruments and could produce actual sound while I am
composing, but could go into "LilyPond" mode, turning off their sound
output but producing a LilyPond score instead when I finally produce my
audio output.
Reply | Threaded
Open this post in threaded view
|

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

Steven Yi
In reply to this post by Bernard Hurley
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

On Tue, Apr 1, 2008 at 2:39 PM, Bernard Hurley <[hidden email]> wrote:

> Hi All,
>
>  First I will explain what I am doing. I am into music for electronic +
>  live instruments. The basic idea is that some instruments could
>  "represent" live instruments and could produce actual sound while I am
>  composing, but could go into "LilyPond" mode, turning off their sound
>  output but producing a LilyPond score instead when I finally produce my
>  audio output.
>
>  I am developing a "LilyWriter" instrument:
>
>  A] In it's global ORC tab it would contain stuff like:
>
>  ;[pre]{
>  #define LilyWriter      #<INSTR_ID>#
>         pyinit
>         pyruni {{
>  def hello():
>  \t      print "hello - let's see if this works!!!"
>  #------- lots of python code goes here -------
>  }}
>  ;}
>
>  "What's the '\t' for?" I hear you ask. Well, if it is not there, the
>  python ends in the CSD file as:
>
>  def hello():
>  print "hello - let's see if this works!!!"
>  -- etc --
>
>  Python doesn't like this at all!! This leads to my first request:
>
>         Request 1: would it be possible for blue NOT to reformat the
>         code in an instrument's global ORC tab? - At least inside a
>         Csound string of the form {{ ---- }}
>
>  If you actually type this code into blue you will find that the Python
>  gets highlighted as if it were Csound. Leading to:
>
>         Request 2: Could syntax highlighting be turned off inside such
>         strings?
>
>  B] The "LilyWriter" global SCO tab contains:
>
>  i <INSTR_ID> 0 <TOTAL_DUR>
>
>  Now other instruments can be made LilyPond aware, just by using
>  constructions like:
>
>  #ifdef  $LilyWriter
>  ----- some stuff
>  #endif
>
>  This can be done inside the instrument itself or in the global ORC tab
>  of the instrument. The upshot of this is that if the "LilyWriter"
>  instrument is included in the orchestra, then it can write the LilyPond
>  score. I won't go into details but I it is starting to work! If it is
>  not included then no score is produced and maybe the Lily-aware
>  instruments can produce sound. All this requires is ticking one box in
>  blue - quite cool!
>
>  However there is one place where this trick doesn't work - this is in
>  the Global orchestra for the whole project. Code typed into the "Global
>  Orchestra" box on the "global" tab for the project appears in the CSD
>  file BEFORE code tagged with [pre] in an instrument - so it is not
>  possible to use the macro $LilyWriter at this point. This leads to my
>  third request:
>
>         Request 3: Could [pre] be implemented so that it placed code
>         BEFORE the project's global orchestra code? On second thought
>         this might break some people's blue projects - so maybe a new
>         tag [top] could be implemented.
>
>  Requests 1 and 2 are not that urgent - being a matter of an ugly hack
>  and eye candy respectively, but it would be REALLY USEFUL to me if 3,
>  could be implemented.
>
>  Thanks for reading all this!
>
>  Regards,
>
>  Bernard
>
>
>
>  -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  Bluemusic-devel mailing list
>  [hidden email]
>  https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluemusic-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
Reply | Threaded
Open this post in threaded view
|

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

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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluemusic-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel