Hello everyone,

I am always working on the live coding with Csound and I wanted to create
some macros.
So, as Steven suggested, I made a "macro.orc" where I defined all my macros
and I included it in the main CSD file.

Now, the problem is: if I call the macro from an instrument I created,
Csound did not recognise the "$". But, if I define the macro inside the
instrument I use everything goes well.

Am I obliged to define the macro in every instrument?

I am on macOS Mojave, Csound 6.13.

Thank you,
Best, 
j



--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Macros can be defined anywhere Moe or less
There was an issue with needing extra newlines but that is resolved but your version may be too old

Can you create a small example or the output you are seeing?
,
⁣Sent from TypeApp ​

On Dec 13, 2019, 21:37, at 21:37, jacqouemin  wrote:
>Hello everyone,
>
>I am always working on the live coding with Csound and I wanted to
>create
>some macros.
>So, as Steven suggested, I made a "macro.orc" where I defined all my
>macros
>and I included it in the main CSD file.
>
>Now, the problem is: if I call the macro from an instrument I created,
>Csound did not recognise the "$". But, if I define the macro inside the
>instrument I use everything goes well.
>
>Am I obliged to define the macro in every instrument?
>
>I am on macOS Mojave, Csound 6.13.
>
>Thank you,
>Best, 
>j
>
>
>
>--
>Sent from:
>http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
>Csound mailing list
>Csound@listserv.heanet.ie
>https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>Send bugs reports to
>        https://github.com/csound/csound/issues
>Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I recently updated to the latest Csound version for another problem (I am on
6.13).


That's what I see:
---
SECTION 1:
Undefined macro: '$ff'     Error: character $(24)

error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>>>	$ <<<
Parsing failed due to invalid input!
Stopping on parser failure
---



--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Yes, that's exactly what it is happening to me: if I evaluate the $macro
without the #define, I get an error.

So, is there no other way in order to use macros in live coding?
I think it could really be an extremely useful instrument.

Best,

j



--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

yes, the macro is a preprocessor command, replaces stuff before compilation. It's not setting variables in memory.

It's a macro, after all, not actual code.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Dec 2019, at 00:07, Pete Goodeve  wrote:
> 
>> On Fri, Dec 13, 2019 at 04:14:34PM -0700, jacqouemin wrote:
>> I recently updated to the latest Csound version for another problem (I am on
>> 6.13).
>> 
>> 
>> That's what I see:
>> ---
>> SECTION 1:
>> Undefined macro: '$ff'     Error: character $(24)
>> 
>> error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>>>>>    $ <<<
>> Parsing failed due to invalid input!
>> Stopping on parser failure
>> ---
>> 
> Can you expand a bit on exactly what you are sending live in
> each condition?  I tried a quick test, and am also seeing failure,
> but not quite the same...
> 
> Using a very basic test orchestra(Csound 6.14):
> 
>  #define AMACRO #123#
> 
>  instr 1
>    printf_i "Macro value: %d\n", 1, $AMACRO
>  endin
> 
> If I load that whole thing live and run instr 1 it works, but if I send only
> the macro line (with any value), I get:
> 
>   "Parsing failed due to no input!"
> 
> and invoking the instrument again has the value unchanged.
> If I then send the instrument code by itelf again, the macro is
> no longer defined.
> 
> I have to send the whole text again after changing the macro
> value.  If I put the macro in an include file as you did, it's just
> the same -- sending just the #iinclude statement fails.
> 
> It appears that the compiler won't accept a macro definition
> separately from the code that uses it. If you send them together,
> though, it works.
> 
>    -- Pete --
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

ARe you sending each instrument as a single compile?  I suspect you are 
hitting the issue of whether macros are persstent berween compilations.

I have ben thinking abut t overnight and think I have a plan.  More 
aterwhen I awake.

==John ff


On Sat, 14 Dec 2019, Victor Lazzarini wrote:

> yes, the macro is a preprocessor command, replaces stuff before compilation. It's not setting variables in memory.
>
> It's a macro, after all, not actual code.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 14 Dec 2019, at 00:07, Pete Goodeve  wrote:
>>
>>> On Fri, Dec 13, 2019 at 04:14:34PM -0700, jacqouemin wrote:
>>> I recently updated to the latest Csound version for another problem (I am on
>>> 6.13).
>>>
>>>
>>> That's what I see:
>>> ---
>>> SECTION 1:
>>> Undefined macro: '$ff'     Error: character $(24)
>>>
>>> error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>>>>>>    $ <<<
>>> Parsing failed due to invalid input!
>>> Stopping on parser failure
>>> ---
>>>
>> Can you expand a bit on exactly what you are sending live in
>> each condition?  I tried a quick test, and am also seeing failure,
>> but not quite the same...
>>
>> Using a very basic test orchestra(Csound 6.14):
>>
>>  #define AMACRO #123#
>>
>>  instr 1
>>    printf_i "Macro value: %d\n", 1, $AMACRO
>>  endin
>>
>> If I load that whole thing live and run instr 1 it works, but if I send only
>> the macro line (with any value), I get:
>>
>>   "Parsing failed due to no input!"
>>
>> and invoking the instrument again has the value unchanged.
>> If I then send the instrument code by itelf again, the macro is
>> no longer defined.
>>
>> I have to send the whole text again after changing the macro
>> value.  If I put the macro in an include file as you did, it's just
>> the same -- sending just the #iinclude statement fails.
>>
>> It appears that the compiler won't accept a macro definition
>> separately from the code that uses it. If you send them together,
>> though, it works.
>>
>>    -- Pete --
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

>From what we're hearing, macros do no seen persistent, as I would expect.

I think the OP is trying to define it once and then use it in subsequent compilations, but it's not clear.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Dec 2019, at 11:28, john  wrote:
> 
> ARe you sending each instrument as a single compile?  I suspect you are hitting the issue of whether macros are persstent berween compilations.
> 
> I have ben thinking abut t overnight and think I have a plan.  More aterwhen I awake.
> 
> ==John ff
> 
> 
>> On Sat, 14 Dec 2019, Victor Lazzarini wrote:
>> 
>> yes, the macro is a preprocessor command, replaces stuff before compilation. It's not setting variables in memory.
>> 
>> It's a macro, after all, not actual code.
>> 
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 
>>>> On 14 Dec 2019, at 00:07, Pete Goodeve  wrote:
>>>> 
>>>> On Fri, Dec 13, 2019 at 04:14:34PM -0700, jacqouemin wrote:
>>>> I recently updated to the latest Csound version for another problem (I am on
>>>> 6.13).
>>>> 
>>>> 
>>>> That's what I see:
>>>> ---
>>>> SECTION 1:
>>>> Undefined macro: '$ff'     Error: character $(24)
>>>> 
>>>> error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>>>>>>>   $ <<<
>>>> Parsing failed due to invalid input!
>>>> Stopping on parser failure
>>>> ---
>>>> 
>>> Can you expand a bit on exactly what you are sending live in
>>> each condition?  I tried a quick test, and am also seeing failure,
>>> but not quite the same...
>>> 
>>> Using a very basic test orchestra(Csound 6.14):
>>> 
>>> #define AMACRO #123#
>>> 
>>> instr 1
>>>   printf_i "Macro value: %d\n", 1, $AMACRO
>>> endin
>>> 
>>> If I load that whole thing live and run instr 1 it works, but if I send only
>>> the macro line (with any value), I get:
>>> 
>>>  "Parsing failed due to no input!"
>>> 
>>> and invoking the instrument again has the value unchanged.
>>> If I then send the instrument code by itelf again, the macro is
>>> no longer defined.
>>> 
>>> I have to send the whole text again after changing the macro
>>> value.  If I put the macro in an include file as you did, it's just
>>> the same -- sending just the #iinclude statement fails.
>>> 
>>> It appears that the compiler won't accept a macro definition
>>> separately from the code that uses it. If you send them together,
>>> though, it works.
>>> 
>>>   -- Pete --
>>> 
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>       https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>       https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> 
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>       https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Jacques,

We had a couple of discussions of this behavior of the macro system a
couple years ago that yielded these issues:

https://github.com/csound/csound/issues/895
https://github.com/csound/csound/issues/896

I argued at the time along the same lines that macros were unusable in
live coding situations. It has also been a problem for building tools
in Blue that involve recompiling code at runtime. For the time being I
suggest one works just with global variables as constants and
writing/using UDOs when live coding.

If you're interested in having macros persist in the system, I'd
suggest following those issues and adding comments.

Steven


On Sat, Dec 14, 2019 at 5:13 AM jacqouemin  wrote:
>
> Yes, that's exactly what it is happening to me: if I evaluate the $macro
> without the #define, I get an error.
>
> So, is there no other way in order to use macros in live coding?
> I think it could really be an extremely useful instrument.
>
> Best,
>
> j
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Maybe we need better metaprogramming mechanisms for live coding. Macros seem to me not sophisticated enough.

As I said in that thread, something to review for 7. I am all for things that are helpful, but done properly and thought through.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Dec 2019, at 11:33, Steven Yi  wrote:
> 
> Hi Jacques,
> 
> We had a couple of discussions of this behavior of the macro system a
> couple years ago that yielded these issues:
> 
> https://github.com/csound/csound/issues/895
> https://github.com/csound/csound/issues/896
> 
> I argued at the time along the same lines that macros were unusable in
> live coding situations. It has also been a problem for building tools
> in Blue that involve recompiling code at runtime. For the time being I
> suggest one works just with global variables as constants and
> writing/using UDOs when live coding.
> 
> If you're interested in having macros persist in the system, I'd
> suggest following those issues and adding comments.
> 
> Steven
> 
> 
>> On Sat, Dec 14, 2019 at 5:13 AM jacqouemin  wrote:
>> 
>> Yes, that's exactly what it is happening to me: if I evaluate the $macro
>> without the #define, I get an error.
>> 
>> So, is there no other way in order to use macros in live coding?
>> I think it could really be an extremely useful instrument.
>> 
>> Best,
>> 
>> j
>> 
>> 
>> 
>> --
>> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>> 
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
> 
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Hi Josh,

I am able to recompile "instrument 0" code (code outside instrument
blocks) without problems and I use it regularly. For example, I just
tried out this code in live.csound.com:

gitab = ftgen(0, 0, 65536, 10, 1)
;gitab = ftgen(0, 0, 65536, 10, 1, 0.25, 0.1)

instr S1
  asig = oscili(0.25, 440, gitab)
  out(asig, asig)
endin

schedule("S1", 0, 2)

If you evaluate all of that you get a 2 second sine tone. If you
uncomment and evaluate the second ftgen, then go and evaluate the
schedule, you should hear the sound with the updated ftable. I also
tested this with Vim on the desktop and things worked as expected.

Does this address your issue or are you doing something different?

Steven

On Sat, Dec 14, 2019 at 4:48 AM Josh Moore  wrote:
>
> I don't think csound with live coding can parse anything outside of an instrument block. Headers run at init time... I've ran into this same problem with loading ftables on the fly, I have to load them into the instrument. You can't init a ftable in the header live, you have to write the csd and re-open it if you want to use a global header. It makes sense though, csound would have to re-compile everything/all the instruments each time headers are parsed.
>
> I'm using vim and Steven Yi's plugin, maybe live coding is better elsewhere but it seems I've run into a similar wall. :P
>
> On Fri, Dec 13, 2019 at 4:07 PM Pete Goodeve  wrote:
>>
>> On Fri, Dec 13, 2019 at 04:14:34PM -0700, jacqouemin wrote:
>> > I recently updated to the latest Csound version for another problem (I am on
>> > 6.13).
>> >
>> >
>> > That's what I see:
>> > ---
>> > SECTION 1:
>> > Undefined macro: '$ff'     Error: character $(24)
>> >
>> > error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>> > >>>   $ <<<
>> > Parsing failed due to invalid input!
>> > Stopping on parser failure
>> > ---
>> >
>> Can you expand a bit on exactly what you are sending live in
>> each condition?  I tried a quick test, and am also seeing failure,
>> but not quite the same...
>>
>> Using a very basic test orchestra(Csound 6.14):
>>
>>   #define AMACRO #123#
>>
>>   instr 1
>>         printf_i "Macro value: %d\n", 1, $AMACRO
>>   endin
>>
>> If I load that whole thing live and run instr 1 it works, but if I send only
>> the macro line (with any value), I get:
>>
>>    "Parsing failed due to no input!"
>>
>> and invoking the instrument again has the value unchanged.
>> If I then send the instrument code by itelf again, the macro is
>> no longer defined.
>>
>> I have to send the whole text again after changing the macro
>> value.  If I put the macro in an include file as you did, it's just
>> the same -- sending just the #iinclude statement fails.
>>
>> It appears that the compiler won't accept a macro definition
>> separately from the code that uses it. If you send them together,
>> though, it works.
>>
>>         -- Pete --
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

i didn't know that schedule trick, that's neat :P

On Sat, Dec 14, 2019 at 3:41 AM Steven Yi <stevenyi@gmail.com> wrote:

Hi Josh,

I am able to recompile "instrument 0" code (code outside instrument
blocks) without problems and I use it regularly. For example, I just
tried out this code in live.csound.com:

gitab = ftgen(0, 0, 65536, 10, 1)
;gitab = ftgen(0, 0, 65536, 10, 1, 0.25, 0.1)

instr S1
  asig = oscili(0.25, 440, gitab)
  out(asig, asig)
endin

schedule("S1", 0, 2)

If you evaluate all of that you get a 2 second sine tone. If you
uncomment and evaluate the second ftgen, then go and evaluate the
schedule, you should hear the sound with the updated ftable. I also
tested this with Vim on the desktop and things worked as expected.

Does this address your issue or are you doing something different?

Steven

On Sat, Dec 14, 2019 at 4:48 AM Josh Moore <kh405.7h30ry@gmail.com> wrote:
>
> I don't think csound with live coding can parse anything outside of an instrument block. Headers run at init time... I've ran into this same problem with loading ftables on the fly, I have to load them into the instrument. You can't init a ftable in the header live, you have to write the csd and re-open it if you want to use a global header. It makes sense though, csound would have to re-compile everything/all the instruments each time headers are parsed.
>
> I'm using vim and Steven Yi's plugin, maybe live coding is better elsewhere but it seems I've run into a similar wall. :P
>
> On Fri, Dec 13, 2019 at 4:07 PM Pete Goodeve <pete.goodeve@computer.org> wrote:
>>
>> On Fri, Dec 13, 2019 at 04:14:34PM -0700, jacqouemin wrote:
>> > I recently updated to the latest Csound version for another problem (I am on
>> > 6.13).
>> >
>> >
>> > That's what I see:
>> > ---
>> > SECTION 1:
>> > Undefined macro: '$ff'     Error: character $(24)
>> >
>> > error: syntax error, unexpected ERROR_TOKEN  (token "$") line 34:
>> > >>>   $ <<<
>> > Parsing failed due to invalid input!
>> > Stopping on parser failure
>> > ---
>> >
>> Can you expand a bit on exactly what you are sending live in
>> each condition?  I tried a quick test, and am also seeing failure,
>> but not quite the same...
>>
>> Using a very basic test orchestra(Csound 6.14):
>>
>>   #define AMACRO #123#
>>
>>   instr 1
>>         printf_i "Macro value: %d\n", 1, $AMACRO
>>   endin
>>
>> If I load that whole thing live and run instr 1 it works, but if I send only
>> the macro line (with any value), I get:
>>
>>    "Parsing failed due to no input!"
>>
>> and invoking the instrument again has the value unchanged.
>> If I then send the instrument code by itelf again, the macro is
>> no longer defined.
>>
>> I have to send the whole text again after changing the macro
>> value.  If I put the macro in an include file as you did, it's just
>> the same -- sending just the #iinclude statement fails.
>>
>> It appears that the compiler won't accept a macro definition
>> separately from the code that uses it. If you send them together,
>> though, it works.
>>
>>         -- Pete --
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here