Hello,

I've just joined the list again after quite a long absence (I've finally 
got a smart new computer and am back in the world of csound, hooray), so 
apologies if this has been covered already.

I'm using a standard build of csound 5.12, from the repository, on 
ubuntu studio.

I'm making a sort of software modular synth (yeah, I know, it's not the 
most original idea) with each module represented as a csound instrument. 
The instruments are all stored in macros, and communicate with each 
other via the chnset/chnget opcodes. The module/instrument macros are 
all stored in separate files, and are all #include'd into the main CSD. 
The whole thing is managed with a simple host program, written in C with 
ncurses.

With a few modules (10 or 20), everything is fine; as I add more the 
system sometimes segfaults, and once I get to about 40 or 50 csound will 
segfault pretty much every time - without even getting to the 
performance. When it DOES work, there are no audio dropouts and my CPU 
monitor shows very moderate usage.

After googling, I used "strace" but it's a bit over my head really. 
Here's the tail of strace's output:

open("marimba2.rack.csmacro", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=4135, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0x7fa000cdf000
read(4, "$KALIAS(c__notenum'100'100)\n$MID"..., 4096) = 4096
brk(0xcdc000)
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x7fa000c9e000
brk(0xcdb000)                           = 0xcdb000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

So it seems to include the macro files OK. "marimba2.rack.csmacro" is 
the following file which contains the macro calls, the first of which is 
"$KALIAS(..."

My limited understanding of this is that csound seems to be failing to 
allocate enough memory for expanding the instrument macros. Some of them 
are rather long.

Incidentally, I've run the host-generated files with csound in the 
terminal, and the same thing happens.

Is this a known bug, and is there anything I can do about it? My next 
step is to rewrite all the code so it DOESN'T use macros, but I don't 
really want to face that yet - especially if that was never the problem 
in the first place.

Many thanks in advance,

Joe

This is why macros are bad, they are hard to debug. My advice is don't use them, but if you do, instrument them so you can turn on some sort of tracing.

This is why macros are bad, they are hard to debug. My advice is don't use them, but if you do, instrument them so you can turn on some sort of tracing.

On Mar 8, 2011 3:46 AM, "Joseph Sanger" <joe@bbeikaiwa.com> wrote:
> Hello,
>
> I've just joined the list again after quite a long absence (I've finally
> got a smart new computer and am back in the world of csound, hooray), so
> apologies if this has been covered already.
>
> I'm using a standard build of csound 5.12, from the repository, on
> ubuntu studio.
>
> I'm making a sort of software modular synth (yeah, I know, it's not the
> most original idea) with each module represented as a csound instrument.
> The instruments are all stored in macros, and communicate with each
> other via the chnset/chnget opcodes. The module/instrument macros are
> all stored in separate files, and are all #include'd into the main CSD.
> The whole thing is managed with a simple host program, written in C with
> ncurses.
>
> With a few modules (10 or 20), everything is fine; as I add more the
> system sometimes segfaults, and once I get to about 40 or 50 csound will
> segfault pretty much every time - without even getting to the
> performance. When it DOES work, there are no audio dropouts and my CPU
> monitor shows very moderate usage.
>
> After googling, I used "strace" but it's a bit over my head really.
> Here's the tail of strace's output:
>
> open("marimba2.rack.csmacro", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0644, st_size=4135, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> = 0x7fa000cdf000
> read(4, "$KALIAS(c__notenum'100'100)\n$MID"..., 4096) = 4096
> brk(0xcdc000)
> mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x7fa000c9e000
> brk(0xcdb000) = 0xcdb000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> +++ killed by SIGSEGV +++
>
> So it seems to include the macro files OK. "marimba2.rack.csmacro" is
> the following file which contains the macro calls, the first of which is
> "$KALIAS(..."
>
> My limited understanding of this is that csound seems to be failing to
> allocate enough memory for expanding the instrument macros. Some of them
> are rather long.
>
> Incidentally, I've run the host-generated files with csound in the
> terminal, and the same thing happens.
>
> Is this a known bug, and is there anything I can do about it? My next
> step is to rewrite all the code so it DOESN'T use macros, but I don't
> really want to face that yet - especially if that was never the problem
> in the first place.
>
> Many thanks in advance,
>
> Joe
>
> --
>
> Joseph Sanger
> Blueberry Eikaiwa
> www.bbeikaiwa.com
>
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

-- 
Joseph Sanger
Blueberry Eikaiwa
www.bbeikaiwa.com

> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
> avoid using macros. I still wonder if it might be a bug with the macro
> system, I know all the bits of my code work in smaller chunks. The
> trouble is that it would take quite a long time to de-macro everything
> manually and make a (long) test csd.
>
> Thanks again,
>
> Joe
>
> On 08/03/11 20:03, Michael Gogins wrote:

There have been a number of changes in macros, but mainly related to the
new parser.  The strace is rather too low-level.  We see the read cal
which is from freas or scanf etc, and we are not seeing the chapter3
functions.  Running under gdb and getting the backtrace is usually a
better method.  If you are willing to send me the inputs (on
jpff@codemist.co.uk) I will try here on my development and debug-enabled
system.  At presentr I do not feel I have enough information to comment

==John ff



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>> avoid using macros. I still wonder if it might be a bug with the macro
>> system, I know all the bits of my code work in smaller chunks. The
>> trouble is that it would take quite a long time to de-macro everything
>> manually and make a (long) test csd.
>>
>> Thanks again,
>>
>> Joe
>>
>> On 08/03/11 20:03, Michael Gogins wrote:
> There have been a number of changes in macros, but mainly related to the
> new parser.  The strace is rather too low-level.  We see the read cal
> which is from freas or scanf etc, and we are not seeing the chapter3
> functions.  Running under gdb and getting the backtrace is usually a
> better method.  If you are willing to send me the inputs (on
> jpff@codemist.co.uk) I will try here on my development and debug-enabled
> system.  At presentr I do not feel I have enough information to comment
>
> ==John ff
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
Many thanks for offering to help. When you say the "inputs" do you mean 
the .csds and the macro .orcs? I can get them together, but it won't 
make a sound without the host app - I'd rather not send that yet as it's 
quite early stages! - but the host app sends all of the score events and 
chnget/chnset stuff to the csound section. Anyway the problem happens 
before that. I'm at work now, I'll do it when I get home.

Thanks again,

Joe

PS do people using this list usually prefer bottom-posting for answering 
mails?

Another question about your project, did you look at Cabel or consider
the same approach, i.e. using a scripting language such as Python or
Lua to define modules that would then generate Csound code? Such an
approach would be much easier to write, understand, and debug. I think
athenaCL also has a templating approach to generating Csound
orchestras.

Regards,
Mike

On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger  wrote:
> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>
>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>> avoid using macros. I still wonder if it might be a bug with the macro
>>> system, I know all the bits of my code work in smaller chunks. The
>>> trouble is that it would take quite a long time to de-macro everything
>>> manually and make a (long) test csd.
>>>
>>> Thanks again,
>>>
>>> Joe
>>>
>>> On 08/03/11 20:03, Michael Gogins wrote:
>>
>> There have been a number of changes in macros, but mainly related to the
>> new parser.  The strace is rather too low-level.  We see the read cal
>> which is from freas or scanf etc, and we are not seeing the chapter3
>> functions.  Running under gdb and getting the backtrace is usually a
>> better method.  If you are willing to send me the inputs (on
>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>> system.  At presentr I do not feel I have enough information to comment
>>
>> ==John ff
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
> Many thanks for offering to help. When you say the "inputs" do you mean the
> .csds and the macro .orcs? I can get them together, but it won't make a
> sound without the host app - I'd rather not send that yet as it's quite
> early stages! - but the host app sends all of the score events and
> chnget/chnset stuff to the csound section. Anyway the problem happens before
> that. I'm at work now, I'll do it when I get home.
>
> Thanks again,
>
> Joe
>
> PS do people using this list usually prefer bottom-posting for answering
> mails?
>
> --
> Joseph Sanger
> Blueberry Eikaiwa
> www.bbeikaiwa.com
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi there, thanks for the advice - I did look at Cabel, but only on a 
surface level, I have no idea what is going on behind the GUI really. 
I've actually been very happy with the way everything has been going up 
until this point, using csound macros, but if they (or my use/abuse of 
them) continue to cause me problems I'll certainly look at some other 
approaches.

Yours,

Joe

On 08/03/11 22:43, Michael Gogins wrote:
> Another question about your project, did you look at Cabel or consider
> the same approach, i.e. using a scripting language such as Python or
> Lua to define modules that would then generate Csound code? Such an
> approach would be much easier to write, understand, and debug. I think
> athenaCL also has a templating approach to generating Csound
> orchestras.
>
> Regards,
> Mike
>
> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger  wrote:
>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>> system, I know all the bits of my code work in smaller chunks. The
>>>> trouble is that it would take quite a long time to de-macro everything
>>>> manually and make a (long) test csd.
>>>>
>>>> Thanks again,
>>>>
>>>> Joe
>>>>
>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>> There have been a number of changes in macros, but mainly related to the
>>> new parser.  The strace is rather too low-level.  We see the read cal
>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>> functions.  Running under gdb and getting the backtrace is usually a
>>> better method.  If you are willing to send me the inputs (on
>>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>>> system.  At presentr I do not feel I have enough information to comment
>>>
>>> ==John ff
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>> Many thanks for offering to help. When you say the "inputs" do you mean the
>> .csds and the macro .orcs? I can get them together, but it won't make a
>> sound without the host app - I'd rather not send that yet as it's quite
>> early stages! - but the host app sends all of the score events and
>> chnget/chnset stuff to the csound section. Anyway the problem happens before
>> that. I'm at work now, I'll do it when I get home.
>>
>> Thanks again,
>>
>> Joe
>>
>> PS do people using this list usually prefer bottom-posting for answering
>> mails?
>>
>> --
>> Joseph Sanger
>> Blueberry Eikaiwa
>> www.bbeikaiwa.com
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>

Another approach to consider is pure Csound orchestra code and would
work like this:

(1) Define your "modules" as user-defined opcodes in one or more include files.

(2) Patch your "modules" together in named instruments, these are your
"patches." Named instruments can also be "effects" for processing
signals. Each instrument and effect can go into its own file. Use
ftgenonce in the body of the instr definition to keep the function
tables together with the instruments. Use the signal flow opcodes to
define inlets and outlets for your instruments and effects. Not
channels.

(3) In your high-level, user orchestra (the "arrange page" of your
synth, if you will) include your UDO file first, then your patch
files, then wire your patches together using the signal flow opcodes.
Not channels.

This is the approach I myself use, although I haven't created as many
"modules" as you probably would like to do. BTW, you might be able to
borrow a lot of the ones already defined in Cabel for use in your own
system.

Regards,
Mike

On Tue, Mar 8, 2011 at 9:02 AM, Joseph Sanger  wrote:
> Hi there, thanks for the advice - I did look at Cabel, but only on a surface
> level, I have no idea what is going on behind the GUI really. I've actually
> been very happy with the way everything has been going up until this point,
> using csound macros, but if they (or my use/abuse of them) continue to cause
> me problems I'll certainly look at some other approaches.
>
> Yours,
>
> Joe
>
> On 08/03/11 22:43, Michael Gogins wrote:
>>
>> Another question about your project, did you look at Cabel or consider
>> the same approach, i.e. using a scripting language such as Python or
>> Lua to define modules that would then generate Csound code? Such an
>> approach would be much easier to write, understand, and debug. I think
>> athenaCL also has a templating approach to generating Csound
>> orchestras.
>>
>> Regards,
>> Mike
>>
>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger  wrote:
>>>
>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>>
>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>> manually and make a (long) test csd.
>>>>>
>>>>> Thanks again,
>>>>>
>>>>> Joe
>>>>>
>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>>
>>>> There have been a number of changes in macros, but mainly related to the
>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>> better method.  If you are willing to send me the inputs (on
>>>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>>>> system.  At presentr I do not feel I have enough information to comment
>>>>
>>>> ==John ff
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>> Many thanks for offering to help. When you say the "inputs" do you mean
>>> the
>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>> sound without the host app - I'd rather not send that yet as it's quite
>>> early stages! - but the host app sends all of the score events and
>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>> before
>>> that. I'm at work now, I'll do it when I get home.
>>>
>>> Thanks again,
>>>
>>> Joe
>>>
>>> PS do people using this list usually prefer bottom-posting for answering
>>> mails?
>>>
>>> --
>>> Joseph Sanger
>>> Blueberry Eikaiwa
>>> www.bbeikaiwa.com
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>
>
> --
> Joseph Sanger
> Blueberry Eikaiwa
> www.bbeikaiwa.com
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thank you Mike, for such detailed and helpful advice.

I need to go through this very carefully, but it's already getting late 
here (Japan). I just have a couple of questions (although I'll probably 
have more later) - what are the "signal flow opcodes", and why shouldn't 
I use the channel opcodes? Are there any problems with chnget etc.? 
And... ftgenonce doesn't seem to be in my manual!

All the best,

Joe



On 08/03/11 23:17, Michael Gogins wrote:
> Another approach to consider is pure Csound orchestra code and would
> work like this:
>
> (1) Define your "modules" as user-defined opcodes in one or more include files.
>
> (2) Patch your "modules" together in named instruments, these are your
> "patches." Named instruments can also be "effects" for processing
> signals. Each instrument and effect can go into its own file. Use
> ftgenonce in the body of the instr definition to keep the function
> tables together with the instruments. Use the signal flow opcodes to
> define inlets and outlets for your instruments and effects. Not
> channels.
>
> (3) In your high-level, user orchestra (the "arrange page" of your
> synth, if you will) include your UDO file first, then your patch
> files, then wire your patches together using the signal flow opcodes.
> Not channels.
>
> This is the approach I myself use, although I haven't created as many
> "modules" as you probably would like to do. BTW, you might be able to
> borrow a lot of the ones already defined in Cabel for use in your own
> system.
>
> Regards,
> Mike
>
> On Tue, Mar 8, 2011 at 9:02 AM, Joseph Sanger  wrote:
>> Hi there, thanks for the advice - I did look at Cabel, but only on a surface
>> level, I have no idea what is going on behind the GUI really. I've actually
>> been very happy with the way everything has been going up until this point,
>> using csound macros, but if they (or my use/abuse of them) continue to cause
>> me problems I'll certainly look at some other approaches.
>>
>> Yours,
>>
>> Joe
>>
>> On 08/03/11 22:43, Michael Gogins wrote:
>>> Another question about your project, did you look at Cabel or consider
>>> the same approach, i.e. using a scripting language such as Python or
>>> Lua to define modules that would then generate Csound code? Such an
>>> approach would be much easier to write, understand, and debug. I think
>>> athenaCL also has a templating approach to generating Csound
>>> orchestras.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger    wrote:
>>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>>> manually and make a (long) test csd.
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>>> There have been a number of changes in macros, but mainly related to the
>>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>>> better method.  If you are willing to send me the inputs (on
>>>>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>>>>> system.  At presentr I do not feel I have enough information to comment
>>>>>
>>>>> ==John ff
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>> Many thanks for offering to help. When you say the "inputs" do you mean
>>>> the
>>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>>> sound without the host app - I'd rather not send that yet as it's quite
>>>> early stages! - but the host app sends all of the score events and
>>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>>> before
>>>> that. I'm at work now, I'll do it when I get home.
>>>>
>>>> Thanks again,
>>>>
>>>> Joe
>>>>
>>>> PS do people using this list usually prefer bottom-posting for answering
>>>> mails?
>>>>
>>>> --
>>>> Joseph Sanger
>>>> Blueberry Eikaiwa
>>>> www.bbeikaiwa.com
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>
>> --
>> Joseph Sanger
>> Blueberry Eikaiwa
>> www.bbeikaiwa.com
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
>

Another option, if you are a fan of macro style generation of instruments, would be to use m4, which is very similar to c or csound macros, but much more robust. m4 is technically a turing complete programming language that runs via textual substitutions, and is used by some pretty important projects so is well maintained and relatively bug free.

Joseph Sanger wrote:
> Hi there, thanks for the advice - I did look at Cabel, but only on a
> surface level, I have no idea what is going on behind the GUI really.
> I've actually been very happy with the way everything has been going up
> until this point, using csound macros, but if they (or my use/abuse of
> them) continue to cause me problems I'll certainly look at some other
> approaches.
> 
> Yours,
> 
> Joe
> 
> On 08/03/11 22:43, Michael Gogins wrote:
>> Another question about your project, did you look at Cabel or consider
>> the same approach, i.e. using a scripting language such as Python or
>> Lua to define modules that would then generate Csound code? Such an
>> approach would be much easier to write, understand, and debug. I think
>> athenaCL also has a templating approach to generating Csound
>> orchestras.
>>
>> Regards,
>> Mike
>>
>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger  wrote:
>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>> manually and make a (long) test csd.
>>>>>
>>>>> Thanks again,
>>>>>
>>>>> Joe
>>>>>
>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>> There have been a number of changes in macros, but mainly related to
>>>> the
>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>> better method.  If you are willing to send me the inputs (on
>>>> jpff@codemist.co.uk) I will try here on my development and
>>>> debug-enabled
>>>> system.  At presentr I do not feel I have enough information to comment
>>>>
>>>> ==John ff
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             
>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>> "unsubscribe
>>>> csound"
>>>>
>>> Many thanks for offering to help. When you say the "inputs" do you
>>> mean the
>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>> sound without the host app - I'd rather not send that yet as it's quite
>>> early stages! - but the host app sends all of the score events and
>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>> before
>>> that. I'm at work now, I'll do it when I get home.
>>>
>>> Thanks again,
>>>
>>> Joe
>>>
>>> PS do people using this list usually prefer bottom-posting for answering
>>> mails?
>>>
>>> -- 
>>> Joseph Sanger
>>> Blueberry Eikaiwa
>>> www.bbeikaiwa.com
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
> 
> 



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Would it be possible for you to run the same orc as you use in your
host app, write a simple test score and run it all as Csound only?
Just to narrow down the scope for tracking down the problem.
I would not advise against the use of macros, but as Michael says,
they can be hard to debug so it is important to establish a simple way
to narrow down your orc/sco to find problems when they arise. The
modular structure you use might be a good way to go to be able to
strip down and build up test cases too, you just have to figure out
how to do it with your code.
best
Oeyvind

2011/3/8 Joseph Sanger :
> Hi there, thanks for the advice - I did look at Cabel, but only on a surface
> level, I have no idea what is going on behind the GUI really. I've actually
> been very happy with the way everything has been going up until this point,
> using csound macros, but if they (or my use/abuse of them) continue to cause
> me problems I'll certainly look at some other approaches.
>
> Yours,
>
> Joe
>
> On 08/03/11 22:43, Michael Gogins wrote:
>>
>> Another question about your project, did you look at Cabel or consider
>> the same approach, i.e. using a scripting language such as Python or
>> Lua to define modules that would then generate Csound code? Such an
>> approach would be much easier to write, understand, and debug. I think
>> athenaCL also has a templating approach to generating Csound
>> orchestras.
>>
>> Regards,
>> Mike
>>
>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger  wrote:
>>>
>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>>
>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>> manually and make a (long) test csd.
>>>>>
>>>>> Thanks again,
>>>>>
>>>>> Joe
>>>>>
>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>>
>>>> There have been a number of changes in macros, but mainly related to the
>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>> better method.  If you are willing to send me the inputs (on
>>>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>>>> system.  At presentr I do not feel I have enough information to comment
>>>>
>>>> ==John ff
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>> Many thanks for offering to help. When you say the "inputs" do you mean
>>> the
>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>> sound without the host app - I'd rather not send that yet as it's quite
>>> early stages! - but the host app sends all of the score events and
>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>> before
>>> that. I'm at work now, I'll do it when I get home.
>>>
>>> Thanks again,
>>>
>>> Joe
>>>
>>> PS do people using this list usually prefer bottom-posting for answering
>>> mails?
>>>
>>> --
>>> Joseph Sanger
>>> Blueberry Eikaiwa
>>> www.bbeikaiwa.com
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>
>>
>
>
> --
> Joseph Sanger
> Blueberry Eikaiwa
> www.bbeikaiwa.com
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Thank you! I had never come across m4 before - just scanned the 
wikipedia page. What a useful tool. I think this might be the way to go, 
given that I've put quite a lot of work into this already - should be 
fairly trivial to tweak what I've done.

Joe

On 08/03/11 23:28, Justin Glenn Smith wrote:
> Another option, if you are a fan of macro style generation of instruments, would be to use m4, which is very similar to c or csound macros, but much more robust. m4 is technically a turing complete programming language that runs via textual substitutions, and is used by some pretty important projects so is well maintained and relatively bug free.
>
> Joseph Sanger wrote:
>> Hi there, thanks for the advice - I did look at Cabel, but only on a
>> surface level, I have no idea what is going on behind the GUI really.
>> I've actually been very happy with the way everything has been going up
>> until this point, using csound macros, but if they (or my use/abuse of
>> them) continue to cause me problems I'll certainly look at some other
>> approaches.
>>
>> Yours,
>>
>> Joe
>>
>> On 08/03/11 22:43, Michael Gogins wrote:
>>> Another question about your project, did you look at Cabel or consider
>>> the same approach, i.e. using a scripting language such as Python or
>>> Lua to define modules that would then generate Csound code? Such an
>>> approach would be much easier to write, understand, and debug. I think
>>> athenaCL also has a templating approach to generating Csound
>>> orchestras.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger   wrote:
>>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>>> manually and make a (long) test csd.
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>>> There have been a number of changes in macros, but mainly related to
>>>>> the
>>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>>> better method.  If you are willing to send me the inputs (on
>>>>> jpff@codemist.co.uk) I will try here on my development and
>>>>> debug-enabled
>>>>> system.  At presentr I do not feel I have enough information to comment
>>>>>
>>>>> ==John ff
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>
>>>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>>>> "unsubscribe
>>>>> csound"
>>>>>
>>>> Many thanks for offering to help. When you say the "inputs" do you
>>>> mean the
>>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>>> sound without the host app - I'd rather not send that yet as it's quite
>>>> early stages! - but the host app sends all of the score events and
>>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>>> before
>>>> that. I'm at work now, I'll do it when I get home.
>>>>
>>>> Thanks again,
>>>>
>>>> Joe
>>>>
>>>> PS do people using this list usually prefer bottom-posting for answering
>>>> mails?
>>>>
>>>> -- 
>>>> Joseph Sanger
>>>> Blueberry Eikaiwa
>>>> www.bbeikaiwa.com
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Hi there,

Thanks - but yes I have done this, as I originally thought it was my 
limited understanding of the C API. Unfortunately exactly the same thing 
happened. John Ffitch has kindly offered to run it through his debugging 
system, so I'll see what he says soon.

Unfortunately it's bedtime here, so it'll have to wait 'till tomorrow!

Many thanks,

Joe

On 08/03/11 23:30, Oeyvind Brandtsegg wrote:
> Would it be possible for you to run the same orc as you use in your
> host app, write a simple test score and run it all as Csound only?
> Just to narrow down the scope for tracking down the problem.
> I would not advise against the use of macros, but as Michael says,
> they can be hard to debug so it is important to establish a simple way
> to narrow down your orc/sco to find problems when they arise. The
> modular structure you use might be a good way to go to be able to
> strip down and build up test cases too, you just have to figure out
> how to do it with your code.
> best
> Oeyvind
>
> 2011/3/8 Joseph Sanger:
>> Hi there, thanks for the advice - I did look at Cabel, but only on a surface
>> level, I have no idea what is going on behind the GUI really. I've actually
>> been very happy with the way everything has been going up until this point,
>> using csound macros, but if they (or my use/abuse of them) continue to cause
>> me problems I'll certainly look at some other approaches.
>>
>> Yours,
>>
>> Joe
>>
>> On 08/03/11 22:43, Michael Gogins wrote:
>>> Another question about your project, did you look at Cabel or consider
>>> the same approach, i.e. using a scripting language such as Python or
>>> Lua to define modules that would then generate Csound code? Such an
>>> approach would be much easier to write, understand, and debug. I think
>>> athenaCL also has a templating approach to generating Csound
>>> orchestras.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Mar 8, 2011 at 7:26 AM, Joseph Sanger    wrote:
>>>> On 08/03/11 20:38, jpff@cs.bath.ac.uk wrote:
>>>>>> OK, thanks for the advice - so perhaps I should rewrite it anyway, to
>>>>>> avoid using macros. I still wonder if it might be a bug with the macro
>>>>>> system, I know all the bits of my code work in smaller chunks. The
>>>>>> trouble is that it would take quite a long time to de-macro everything
>>>>>> manually and make a (long) test csd.
>>>>>>
>>>>>> Thanks again,
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> On 08/03/11 20:03, Michael Gogins wrote:
>>>>> There have been a number of changes in macros, but mainly related to the
>>>>> new parser.  The strace is rather too low-level.  We see the read cal
>>>>> which is from freas or scanf etc, and we are not seeing the chapter3
>>>>> functions.  Running under gdb and getting the backtrace is usually a
>>>>> better method.  If you are willing to send me the inputs (on
>>>>> jpff@codemist.co.uk) I will try here on my development and debug-enabled
>>>>> system.  At presentr I do not feel I have enough information to comment
>>>>>
>>>>> ==John ff
>>>>>
>>>>>
>>>>>
>>>>> Send bugs reports to the Sourceforge bug tracker
>>>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>>> Discussions of bugs and features can be posted here
>>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>>> csound"
>>>>>
>>>> Many thanks for offering to help. When you say the "inputs" do you mean
>>>> the
>>>> .csds and the macro .orcs? I can get them together, but it won't make a
>>>> sound without the host app - I'd rather not send that yet as it's quite
>>>> early stages! - but the host app sends all of the score events and
>>>> chnget/chnset stuff to the csound section. Anyway the problem happens
>>>> before
>>>> that. I'm at work now, I'll do it when I get home.
>>>>
>>>> Thanks again,
>>>>
>>>> Joe
>>>>
>>>> PS do people using this list usually prefer bottom-posting for answering
>>>> mails?
>>>>
>>>> --
>>>> Joseph Sanger
>>>> Blueberry Eikaiwa
>>>> www.bbeikaiwa.com
>>>>
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>>> csound"
>>>>
>>>>
>>>
>>
>> --
>> Joseph Sanger
>> Blueberry Eikaiwa
>> www.bbeikaiwa.com
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

> Hi there,
>
> Thanks - but yes I have done this, as I originally thought it was my
> limited understanding of the C API. Unfortunately exactly the same thing
> happened. John Ffitch has kindly offered to run it through his debugging
> system, so I'll see what he says soon.
>
> Unfortunately it's bedtime here, so it'll have to wait 'till tomorrow!
>
>

I have found a problem on 64bit machines, and with thta fioxed it runs OK
here
What I do not know is if this as on a 64bit machine.

I will scan for the same stupidity elsewhere

==John

(ack to ELSEIF problems)



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

On 09/03/11 03:39, jpff@cs.bath.ac.uk wrote:
>> Hi there,
>>
>> Thanks - but yes I have done this, as I originally thought it was my
>> limited understanding of the C API. Unfortunately exactly the same thing
>> happened. John Ffitch has kindly offered to run it through his debugging
>> system, so I'll see what he says soon.
>>
>> Unfortunately it's bedtime here, so it'll have to wait 'till tomorrow!
>>
>>
> I have found a problem on 64bit machines, and with thta fioxed it runs OK
> here
> What I do not know is if this as on a 64bit machine.
>
> I will scan for the same stupidity elsewhere
>
> ==John
>
> (ack to ELSEIF problems)
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
I should have said - I'm also using 64-bit. Apologies that I didn't 
mention earlier.

Joe