feature request: Macro tab on instrument definition

[Bernard Hurley]

Hi,

I'm not sure if this or the user list is the correct one for this. I
have been adding lines like:
        #define flute #<INSTR_ID>#
to both the "Global Orchestra" and the "Global Score" tabs. There are
two issues:

        1) It would be nice just to add this once.
        2) More importantly, the macro definition is not placed high
        enough in the global score for me to use code like:
        prealloc $flute, 5
       
A solution would be to have a "Macro" tab that would put identical code
near the top of each section.

Regards,

Bernard

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[hannes kahl]

> Hi,
>
> I'm not sure if this or the user list is the correct one for this. I
> have been adding lines like:
> #define flute #<INSTR_ID>#
> to both the "Global Orchestra" and the "Global Score" tabs. There are
> two issues:
>
>         1) It would be nice just to add this once.
>         2) More importantly, the macro definition is not placed high
>         enough in the global score for me to use code like:
>         prealloc $flute, 5
>        
> A solution would be to have a "Macro" tab that would put identical code
> near the top of each section.
>
> Regards,
>
> Bernard

I realy agree with this!
Ciao Hannes
--
 |_____________________________________________________|
 |_____________________________________________________|
                         www.uni-weimar.de/~ubbe7936
 |_____________________________________________________|
                                     Hannes Kahl
 |_____________________________________________________|
 |_____________________________________________________|
                     

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Steven Yi]

Hi Bernard,

I'm not a fan of macros and don't think they are really necessary when
using blue, plus currently the Csound system of macro's does not have
a single macro system and I don't particularly want to spend time to
create a macro system in blue when I think it would lead to creating
harder to reuse projects and reduces maintainability.  Also, the idea
of implementing a macro system is really not so simple as it would
have to get run inline on every instrument generated and all score
generated for each soundObject as blue would need to expand macros
before further processing to apply the time behavior of the
soundObject or the noteProcessors on the sObj or the soundLayer, and
so on and so on for all nestings within polyObjects.

For your case, if you want to use these kinds of macro's, you could
put them in the global orc and sco of your instrument using pre blocks
to push it above the rest of the global orc:

http://csounds.com/stevenyi/blue/usermanual/html/ch02s07s03.html

You could probably add the prealloc command with the instrument
definition too if it's something that is associated with the
instrument.

steven


On Sun, Feb 24, 2008 at 1:19 PM, Bernard Hurley <bernard@...> wrote:

> Hi,
>
>  I'm not sure if this or the user list is the correct one for this. I
>  have been adding lines like:
>         #define flute #<INSTR_ID>#
>  to both the "Global Orchestra" and the "Global Score" tabs. There are
>  two issues:
>
>         1) It would be nice just to add this once.
>         2) More importantly, the macro definition is not placed high
>         enough in the global score for me to use code like:
>                  prealloc $flute, 5
>
>  A solution would be to have a "Macro" tab that would put identical code
>  near the top of each section.
>
>  Regards,
>
>  Bernard
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Bluemusic-devel mailing list
>  Bluemusic-devel@...
>  https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Bernard Hurley]

Hi Steve,

I'm not a fan of macros in general. I agree that a full blown macro
processor would cause more problems than it would solve. But I do like
to use names to refer to instruments by names. Given that names are not
stored in the instrument library, the easiest thing to so is use a
simple macro. When I first saw the name field in the instrument
definition, I thought it might be for giving the instrument a name - an
instrument can have both a numerical ID and a name.

"pre" does not push the code high up enough in the global orchestra. The
macro really needs to go before the code defined in the "Global" tab in
the definition of the whole score. Maybe a "macro" variable could be
used to do this. "pre" does not work at all for the score.

Cheers,

Bernard


On Sun, 2008-02-24 at 21:09 -0800, Steven Yi wrote:

> Hi Bernard,
>
> I'm not a fan of macros and don't think they are really necessary when
> using blue, plus currently the Csound system of macro's does not have
> a single macro system and I don't particularly want to spend time to
> create a macro system in blue when I think it would lead to creating
> harder to reuse projects and reduces maintainability.  Also, the idea
> of implementing a macro system is really not so simple as it would
> have to get run inline on every instrument generated and all score
> generated for each soundObject as blue would need to expand macros
> before further processing to apply the time behavior of the
> soundObject or the noteProcessors on the sObj or the soundLayer, and
> so on and so on for all nestings within polyObjects.
>
> For your case, if you want to use these kinds of macro's, you could
> put them in the global orc and sco of your instrument using pre blocks
> to push it above the rest of the global orc:
>
> http://csounds.com/stevenyi/blue/usermanual/html/ch02s07s03.html
>
> You could probably add the prealloc command with the instrument
> definition too if it's something that is associated with the
> instrument.
>
> steven
>
>
> On Sun, Feb 24, 2008 at 1:19 PM, Bernard Hurley <bernard@...> wrote:
> > Hi,
> >
> >  I'm not sure if this or the user list is the correct one for this. I
> >  have been adding lines like:
> >         #define flute #<INSTR_ID>#
> >  to both the "Global Orchestra" and the "Global Score" tabs. There are
> >  two issues:
> >
> >         1) It would be nice just to add this once.
> >         2) More importantly, the macro definition is not placed high
> >         enough in the global score for me to use code like:
> >                  prealloc $flute, 5
> >
> >  A solution would be to have a "Macro" tab that would put identical code
> >  near the top of each section.
> >
> >  Regards,
> >
> >  Bernard
> >
> >  -------------------------------------------------------------------------
> >  This SF.net email is sponsored by: Microsoft
> >  Defy all challenges. Microsoft(R) Visual Studio 2008.
> >  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >  _______________________________________________
> >  Bluemusic-devel mailing list
> >  Bluemusic-devel@...
> >  https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
> >
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Bernard Hurley]

Hi Steve,

Thinking about it, a solution to using instrument names in blue might be
as follows (I want to think this out before submitting it to the
tracker):

        1) Have an (optional) "symbolic name" field in an instrument
        definition that is stored in the library.
       
        2) If the symbolic name is (say) "flute" allow <<flute>> to
        substitute the same substitution <INSTR_ID>, but do it anywhere
        in the sco or orc (this would involve a bit of preprocessing
        -but not much). Similarly <N<flute>> could do the same
        substitution as <INSTR_NAME>.
       
Apart from doing things like referring to instruments by name in the
sco, it would make it much easier to use a whole range of opcodes -
"mgassign", "prealloc", "subinstr" and "event" to mention just a few.
For example you could write code such as:

        event "i", <<flute>>, 3, 10

There would be a problem of name clashes, but this is the case anyway if
you wish to name the instruments. The same problem occurs with macros.
With my proposal (unlike with macros) it would be possible for blue to
detect this and issue a warning.

With a system like this there would be no real need for non-numeric IDs,
unless one wanted to use "+" names, but I don't think this is much of an
issue. The Instr ID could then just be allowed to take care of itself.

Cheers

Bernard


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Steven Yi]

Hi Bernard,

I've taken a look and have to say that I'm not very fond of the idea
of using <<name>> as it seems confusing and may have errors, say if
you had a parameter named <name> in a BSB instrument.

If you need to use the instrument number that a named instrument uses,
I think you can get it by using p1, which should have the number
assigned to the instrument.

Handling + in names makes sense, but the rest I think should be
do-able with just using Csound's standard named instrument feature.

steven

On Mon, Feb 25, 2008 at 6:13 AM, Bernard Hurley <bernard@...> wrote:

> Hi Steve,
>
>  Thinking about it, a solution to using instrument names in blue might be
>  as follows (I want to think this out before submitting it to the
>  tracker):
>
>         1) Have an (optional) "symbolic name" field in an instrument
>         definition that is stored in the library.
>
>         2) If the symbolic name is (say) "flute" allow <<flute>> to
>         substitute the same substitution <INSTR_ID>, but do it anywhere
>         in the sco or orc (this would involve a bit of preprocessing
>         -but not much). Similarly <N<flute>> could do the same
>         substitution as <INSTR_NAME>.
>
>  Apart from doing things like referring to instruments by name in the
>  sco, it would make it much easier to use a whole range of opcodes -
>  "mgassign", "prealloc", "subinstr" and "event" to mention just a few.
>  For example you could write code such as:
>
>         event "i", <<flute>>, 3, 10
>
>  There would be a problem of name clashes, but this is the case anyway if
>  you wish to name the instruments. The same problem occurs with macros.
>  With my proposal (unlike with macros) it would be possible for blue to
>  detect this and issue a warning.
>
>  With a system like this there would be no real need for non-numeric IDs,
>  unless one wanted to use "+" names, but I don't think this is much of an
>  issue. The Instr ID could then just be allowed to take care of itself.
>
>  Cheers
>
>  Bernard
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel