Ok, I know it's totally not cool to pressure any of the developers, but 
if someone is looking for something to fix ... I might actually be able 
to use csound5 in a show next week.

Csound5 ( and varga csound 4 for that matter ) totally crap out if they 
are given both long scores and long score lines at the same time past a 
certain memory threshold. I have no clue what this means, but it's 
clearly a matter of running out of room, I can comment any one of the 
patch loading lines out and it works, but put too many in, and I seg 
fault. I have instruments that use included files to send 128 pfields 
into tables. Too many of those and it gives me:

sread requesting more memory
Csound Tidyup Segmentation fault.

They are passed there fields like so:
i135 0 0.1 3100 #include "bass.pat"
- where bass is a text file of numbers.
However, I got the same behaviour when I used a preprocessor to expand 
it to just
i135 0 0.1 3100    1 2 3 4 5 6 etc for 127 values


Thanks for listening
Iain


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> sread requesting more memory
> Csound Tidyup Segmentation fault.

Could you post a backtrace ?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The current sources I have (not in CVS yet) can parse the attached CSD,
but still need some testing.

Iain Duncan wrote:

> Ok, I know it's totally not cool to pressure any of the developers, but 
> if someone is looking for something to fix ... I might actually be able 
> to use csound5 in a show next week.
> 
> Csound5 ( and varga csound 4 for that matter ) totally crap out if they 
> are given both long scores and long score lines at the same time past a 
> certain memory threshold. I have no clue what this means, but it's 
> clearly a matter of running out of room, I can comment any one of the 
> patch loading lines out and it works, but put too many in, and I seg 
> fault. I have instruments that use included files to send 128 pfields 
> into tables. Too many of those and it gives me:
> 
> sread requesting more memory
> Csound Tidyup Segmentation fault.
> 
> They are passed there fields like so:
> i135 0 0.1 3100 #include "bass.pat"
> - where bass is a text file of numbers.
> However, I got the same behaviour when I used a preprocessor to expand 
> it to just
> i135 0 0.1 3100    1 2 3 4 5 6 etc for 127 values
> 
> 
> Thanks for listening
> Iain

Istvan Varga wrote:

> The current sources I have (not in CVS yet) can parse the attached CSD,
> but still need some testing.

Oddly, the original code can read the CSD without problems as well, even
if I increase the size of the score (by copying and pasting the lines many
times) to more than 3 MB, and have instruments with more than 500 p-fields.
I cannot reproduce the error.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sure. I think. What's a backtrace? ; )

Iain


Istvan Varga wrote:
> Iain Duncan wrote:
> 
>> sread requesting more memory
>> Csound Tidyup Segmentation fault.
> 
> 
> Could you post a backtrace ?
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan, before committing can you test whether they can parse the same 
thing with all the i1 calls happening at the same time? Your example has 
them all starting at different times. I find the problem happens when I 
have a bunch starting at once, for example

i135 1 0.1 3109     lots of numbers
i135 1 0.1 3110     lots of numbers
i135 1 0.1 3111     lots of numbers
i135 1 0.1 3112     lots of numbers
i135 1 0.1 3113     lots of numbers
i135 1 0.1 3114     lots of numbers

This is what I do when I have a bunch of patch changes automated at the 
same time between tracks. If the above is working ok with your new 
sources, I'll try that out before zipping up an example. It's not a 
horrendous rush, I've got just over a week before the show.

I am also very suprised by how csound handles it too, for some reason it 
gets a massive cpu spike even though instrument 135 makes *one* table 
write per pfield for one kcycle and then turns itself off. This seems 
really strange to me, it's just not much table writing compared to any 
audio rate stuff. But 8 patch instruments all writing 128 points once at 
the same time just skyrockets the cpu for a bit, like from 60% to 
85%-90% use.

Thanks for helping.
Iain


Istvan Varga wrote:
> The current sources I have (not in CVS yet) can parse the attached CSD,
> but still need some testing.
> 
> Iain Duncan wrote:
> 
>> Ok, I know it's totally not cool to pressure any of the developers, 
>> but if someone is looking for something to fix ... I might actually be 
>> able to use csound5 in a show next week.
>>
>> Csound5 ( and varga csound 4 for that matter ) totally crap out if 
>> they are given both long scores and long score lines at the same time 
>> past a certain memory threshold. I have no clue what this means, but 
>> it's clearly a matter of running out of room, I can comment any one of 
>> the patch loading lines out and it works, but put too many in, and I 
>> seg fault. I have instruments that use included files to send 128 
>> pfields into tables. Too many of those and it gives me:
>>
>> sread requesting more memory
>> Csound Tidyup Segmentation fault.
>>
>> They are passed there fields like so:
>> i135 0 0.1 3100 #include "bass.pat"
>> - where bass is a text file of numbers.
>> However, I got the same behaviour when I used a preprocessor to expand 
>> it to just
>> i135 0 0.1 3100    1 2 3 4 5 6 etc for 127 values
>>
>>
>> Thanks for listening
>> Iain


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> Sure. I think. What's a backtrace? ; )

You can get a backtrace by running Csound with gdb (assuming that you
have it installed):
   gdb --args ./csound  [csound options...]
At the gdb command prompt, type:
   run
Csound will then run as normal, and, of course, crash when the
bug that you have found is triggered. The gdb prompt appears again,
so type:
   backtrace
and send the messages printed. Then you can quit gdb with:
   quit

For gdb to work, Csound should be compiled with debugging information
(that is, without the noDebug=1 or gcc3opt=1 scons options). To debug
memory access problems, it may be useful to add customLIBS=-lefence
if you have that library installed, but this is optional.

However, you may want to try the updated CVS sources first to find
out if the crash still occurs.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Iain Duncan wrote:

> I find the problem happens when I have a bunch starting at once, for example
> 
> i135 1 0.1 3109     lots of numbers
> i135 1 0.1 3110     lots of numbers
> i135 1 0.1 3111     lots of numbers
> i135 1 0.1 3112     lots of numbers
> i135 1 0.1 3113     lots of numbers
> i135 1 0.1 3114     lots of numbers

Well, the attached examples can crash Csound 4.24.0 (csound_static) and the
2005-03-17 Csound5 Win32 file release (running under WINE), but interestingly
the CSD files only crash one particular version and not both.
However, the current CVS version that I updated earlier today can parse
all the examples without problems (or the right test file was not found
yet; very long lines in the excess of 3000 characters are probably still
not safe).

Thanks Istvan, that seems to have solved it.

If anyone has clue as to why the technique I'm using sends the cpu use 
up so freaking much, or an alternate suggestion for a more efficient way 
to dynamically load patch tables from the score, I'd love to hear it.

It's really weird, if I send say 12 patch loads all at once, the cpu use 
goes up to about 90%, and then stays there. But if I stagger them out, 
then it only goes up to about 70%. But why does it stay there? The 
instrument is only one for one kcycle! Attached is the instrument I'm 
using. It's number 135.

Iain


Istvan Varga wrote:
> Iain Duncan wrote:
> 
>> I find the problem happens when I have a bunch starting at once, for 
>> example
>>
>> i135 1 0.1 3109     lots of numbers
>> i135 1 0.1 3110     lots of numbers
>> i135 1 0.1 3111     lots of numbers
>> i135 1 0.1 3112     lots of numbers
>> i135 1 0.1 3113     lots of numbers
>> i135 1 0.1 3114     lots of numbers
> 
> 
> Well, the attached examples can crash Csound 4.24.0 (csound_static) and the
> 2005-03-17 Csound5 Win32 file release (running under WINE), but 
> interestingly
> the CSD files only crash one particular version and not both.
> However, the current CVS version that I updated earlier today can parse
> all the examples without problems (or the right test file was not found
> yet; very long lines in the excess of 3000 characters are probably still
> not safe).

I cannot reproduce the problem of CPU usage remaining high even after the
note was turned off. With the attached test files, starting 64 instances of
instr 135 at the same time does require -B 1024 to avoid buffer underruns,
but there is no high CPU usage once the table writing is done.
The examples may be too simple, though.

ramper2.csd uses the event opcode to replace the contents of the existing
table. Of course, if this method is suitable, you may very well just use
"f" statements in the score to update the table contents, but I do not
know how ramper.orc is intended to be used.