I'm still hoping someone can help me with my display problems under Linux.
Tarmo Johannes suggested I try compiling from the Git sources, but that
made no difference.  In Csound5, dispfft works but then locks up.  In
Csound6, function displays (including those from dispfft but also the
usual function-table contents displays) appear as ASCII art, with a
message saying displays have been suppressed - just as if I'd given the -g
option, even though I haven't.

How can I either get dispfft to really work without locking up in Csound5,
or get graphical displays in Csound6?

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/

There were changes made to grahics/display in cs6 as it seemed that most 
peope dd not want them -- not me I might add.  Ty the commandline option
--displays

Might work

==John ff

On Wed, 5 Feb 2014, jpff wrote:
> There were changes made to grahics/display in cs6 as it seemed that most peope
> dd not want them -- not me I might add.  Ty the commandline option
> --displays

It makes no difference.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/

On Wed, 5 Feb 2014, mskala@ansuz.sooke.bc.ca wrote:
> > dd not want them -- not me I might add.  Ty the commandline option
> > --displays
>
> It makes no difference.

Further to that:  I dug around in the code and found that there is a field
called "nographs" which, if set nonzero, causes displays to be forced to
ASCII.  And there doesn't seem to be any code capable of setting it to
zero.  Adding a line to the code that handles the "--displays" option to
make it set nographs to zero causes them to come up in a window as
desired.  By the way, "--displays" isn't mentioned in the options list
produced by "--help".  I may attempt to create a clean patch to improve
this situation and submit it.

But the latest Git sources for Csound6, modified as described, still have
the same problem I saw with Csound5:  dispfft will lock up, showing an
empty pair of coordinate axes with no spectrum, and once it does that, it
will never show a spectrum again for the rest of the run.  Any thoughts on
what might be done about this?

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/

I just ran the dispfft.csd example from the manual with Csound 6,
using --displays. The FFT showed here (I am using OSX 10.9). This was
shown using the FLTK display.

What OS are you using?  Perhaps it is specific to the OS.

steven

On Wed, Feb 5, 2014 at 9:42 PM,   wrote:
> On Wed, 5 Feb 2014, mskala@ansuz.sooke.bc.ca wrote:
>> > dd not want them -- not me I might add.  Ty the commandline option
>> > --displays
>>
>> It makes no difference.
>
> Further to that:  I dug around in the code and found that there is a field
> called "nographs" which, if set nonzero, causes displays to be forced to
> ASCII.  And there doesn't seem to be any code capable of setting it to
> zero.  Adding a line to the code that handles the "--displays" option to
> make it set nographs to zero causes them to come up in a window as
> desired.  By the way, "--displays" isn't mentioned in the options list
> produced by "--help".  I may attempt to create a clean patch to improve
> this situation and submit it.
>
> But the latest Git sources for Csound6, modified as described, still have
> the same problem I saw with Csound5:  dispfft will lock up, showing an
> empty pair of coordinate axes with no spectrum, and once it does that, it
> will never show a spectrum again for the rest of the run.  Any thoughts on
> what might be done about this?
>
> --
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before principles.
> http://ansuz.sooke.bc.ca/
>
>
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>             https://sourceforge.net/p/csound/tickets/
> csound5:
>             https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

On Wed, 5 Feb 2014, Steven Yi wrote:
> I just ran the dispfft.csd example from the manual with Csound 6,
> using --displays. The FFT showed here (I am using OSX 10.9). This was
> shown using the FLTK display.
>
> What OS are you using?  Perhaps it is specific to the OS.

I'm using Linux on an amd64.  For me, the display comes up in a window if
and only if I modify the source code to set "nographs" to zero.  That
works as far as it goes, so getting the window to come up at all is no
longer an issue.

However, this modification only restores it to work as well as Csound5
used to work - which is not really good enough.  The FFT display still
locks up after a few minutes of use.  So far I haven't been able to come
up with a clean example that reliably demonstrates the misbehaviour, but
I'll keep working on that.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/

I remember fixing something in dispfft after the 6.02 release. Can you make sure you have the latest code?
It's in GIT branch develop (the master branch will not have it).

Victor
On 6 Feb 2014, at 05:01, mskala@ansuz.sooke.bc.ca wrote:

> On Wed, 5 Feb 2014, Steven Yi wrote:
>> I just ran the dispfft.csd example from the manual with Csound 6,
>> using --displays. The FFT showed here (I am using OSX 10.9). This was
>> shown using the FLTK display.
>> 
>> What OS are you using?  Perhaps it is specific to the OS.
> 
> I'm using Linux on an amd64.  For me, the display comes up in a window if
> and only if I modify the source code to set "nographs" to zero.  That
> works as far as it goes, so getting the window to come up at all is no
> longer an issue.
> 
> However, this modification only restores it to work as well as Csound5
> used to work - which is not really good enough.  The FFT display still
> locks up after a few minutes of use.  So far I haven't been able to come
> up with a clean example that reliably demonstrates the misbehaviour, but
> I'll keep working on that.
> 
> -- 
> Matthew Skala
> mskala@ansuz.sooke.bc.ca                 People before principles.
> http://ansuz.sooke.bc.ca/
> 
> 
> Send bugs reports to the Sourceforge bug trackers
> csound6:
>            https://sourceforge.net/p/csound/tickets/
> csound5:
>            https://sourceforge.net/p/csound/bugs/
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

On Thu, 6 Feb 2014, Victor Lazzarini wrote:
> I remember fixing something in dispfft after the 6.02 release. Can you make sure you have the latest code?
> It's in GIT branch develop (the master branch will not have it).

Yes, I have the latest code from the develop branch in Git.  It still fails.

However, in trying to construct a minimal example to demonstrate the
problem, I think I've figured out what's going on and a workaround
acceptable for my own purposes.  Here's the issue:

The dispfft opcode automatically expands its scale to make the signal fit
in the display, but never contracts it; so the scale will always be
appropriate to the largest peak seen so far in the input.

I was using it in decibel mode.  My input (having just come out of a
simple software synthesizer) contained periods of silence that were truly
absolute silence.  And the logarithm of zero is not a finite number.  You
see where this is going, I'm sure.

As soon as there was a window of all zeroes in the signal, dispfft would
expand its scale to be infinitely large, at which point the signal would
never be visible again.  It took me longer than it might have to notice
this because I was, for other reasons, running dispfft conditionally on
the RMS level of the signal, so that it usually wouldn't run during
periods of silence.  It was only rarely and unpredictably that a long
enough chunk of silence would make it through that condition and trigger
the problem.

Using the denorm opcode to add a tiny amount of noise prevents dispfft
from locking up.  However, the actual dynamic range of my signal when it
isn't silent, is much smaller than the dynamic range between the
non-silent signal and denorm's enhanced silence, so dispfft's display
still scales to be bigger than I would like in order to accomodate the
denorm noise floor far below the signal, and the peaks of my signal appear
very small.  I'm getting a more useful display by adding some noise from
the random opcode with amplitude about -80dB, to limit the overall dynamic
range to about that.

My immediate problem is solved.  It remains that it sure would be nice for
dispfft to handle truly silent input more gracefully, and maybe allow more
user control of the display scale in decibel mode.  What I'd really like
would be to set a fixed top and bottom amplitude for the spectral display
- no automatic range changes triggered by the signal - and then if the
signal went below or above the limits, those parts of the trace just
wouldn't be plotted.

-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                 People before principles.
http://ansuz.sooke.bc.ca/

That should be possible alright. Could you please file a feature request ticket, adding
a simple example demonstrating the issue if at all possible.

Victor
On 8 Feb 2014, at 17:43, mskala@ansuz.sooke.bc.ca wrote:

> My immediate problem is solved.  It remains that it sure would be nice for
> dispfft to handle truly silent input more gracefully, and maybe allow more
> user control of the display scale in decibel mode.  What I'd really like
> would be to set a fixed top and bottom amplitude for the spectral display
> - no automatic range changes triggered by the signal - and then if the
> signal went below or above the limits, those parts of the trace just
> wouldn't be plotted.