gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Zoom peculiarities

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> the mouse should issue
>
> replot [x_left:x_right] [y_bottom:y_top] 


Of course, the "u"nzoom function would be implemented by gplt_x11 just 
issuing a

replot

Dan

Re: Zoom peculiarities

[Daniel J S. <dan...@ie...>]

Yes, I believe that "replot" should have its own ranges options.  Try this:

plot [0:50] [-2:2] sin(x)

and attempt to zoom.  It won't zoom!  That certainly isn't a user 
expectation, is it?  So instead of

set xrange [x_left:x_right]
set yrange [y_bottom:y_top]
replot

the mouse should issue

replot [x_left:x_right] [y_bottom:y_top]

I think that fixes all confusion then if the ranges in replot override 
the current ranges and are then simply discarded.

Dan




Daniel J Sebald wrote:

>
>
> Daniel J Sebald wrote:
>
>>
>> Thus, the mouse zoom could do a
>>
>> set xrange [:] replot
>> set yrange [:] replot
>> replot
>>
>> and not disturb the overall settings.
>
>
>
> Or, even simpler might be that "replot" has its own {ranges} option. 
> Then one wouldn't have to internally keep track of x_range_replot, 
> y_range_replot, etc.  Just use the values in the
>
> replot [:] [:]
>
> command and discard them.  The consequence is that "replot" by itself 
> has an inherent "unzooming" effect.  Which I think isn't unreasonable.
>
> Dan
>
>
>
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: Zoom peculiarities

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

>
> Thus, the mouse zoom could do a
>
> set xrange [:] replot
> set yrange [:] replot
> replot
>
> and not disturb the overall settings.


Or, even simpler might be that "replot" has its own {ranges} option. 
 Then one wouldn't have to internally keep track of x_range_replot, 
y_range_replot, etc.  Just use the values in the

replot [:] [:]

command and discard them.  The consequence is that "replot" by itself 
has an inherent "unzooming" effect.  Which I think isn't unreasonable.

Dan

Re: Zoom peculiarities

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Wed, 12 May 2004, Daniel J Sebald wrote:
>
>  
>
>>Here is something odd in the latest CVS version.  In the "using.dem" 
>>script, for the first plot, with the mouse active, zoom in on say a top 
>>middle third of the data.  There will be some lines extending below the 
>>bottom border.  The length of the lines seems to vary upon what area was 
>>zoomed.  (That is, do this again and the line lengths may be shorter or 
>>longer by random.)
>>    
>>
>
>'impulses' plots assume the plot has a baseline they can use.  Zooming may
>break that assumption.  There have been problems like this with impulses
>in the past.  So yes, this is a bug, but not an entirely unexpected one.
>

I see what is happening now.  Impulses should behave so that negative 
numbers have a line appearing below y=0.  However, it appears that the 
current behavior does the same thing for *any* border that appears at 
the bottom of the plot.  For example, say the bottom border is at y=15. 
 A value of  17 in the original plot now has a line going from 15 to 17. 
 A value of 14 in the original plot now has a line going from 14 to 15. 
 For some reason, gnuplot thinks it can plot outside the bottom border. 
 There shouldn't be lines below the border.  Agreed?

>>With the first plot still zoomed, go to the command line, hit return and 
>>go to the second plot.  The second plot will be zoomed also.  (Should it 
>>stay zoomed?)  In the window, unzoom the second plot by typing 'u'.  The 
>>ranges don't seem to be very nice.  The image is small.  The second plot 
>>script issues a
>>
>>set xrange [1:8]
>>
>>Is there a problem with setting the range when in zoomed mode?
>>    
>>
>
>No.  There's a more general problem in the way zooming, and especially the
>'u'nzoom hotkey works.  The general problem is that mouse interactions
>change the global state of gnuplot settings.  You can see that happening
>by typing the '6' hotkey: each zooming operation modifies the global range
>settings.
>
>In scripts like our demos, where all settings not explicitly changed
>between plots are assumed to keep the values from the previous plot
>command, that will break massively.  Until we implement separate global
>data sets for each plot, so the mousing code can work on a copy instead of
>the single instance of all the settings we have, I don't think there's
>much that can be done about that.
>
>Workaround: don't zoom in demos; or if you do, remember to unzoom _before_
>you proceed to the next plot. Using 'unzoom' on a different graph than the
>one you zoomed on is IMHO begging for trouble.
>

So, when unzoomed in the second plot, the ranges go back to [*:*] or 
something like that.  But why should the explicit

set xrange [1:8]

be discarded?  Anyway, I don't see how the "each plot has its own 
settings" would change matters.  If one plot is zoomed and then a second 
is generated, what will you use for the ranges of the second plot? 
 You're still going to have this same scenario.

What you are suggesting is useful for the situation where there are 
multiple plot windows and each has its own record of ranges, etc. 
 However to solve this zoom settings across plots problem, it seems to 
me that the only requirement is that range sets from the command line 
and from the mouse be distinguishable.  (But that currently may not be 
the case in Gnuplot.)  It seems to me that you have to have the ability 
to distinguish where the range set originated from, otherwise a good 
solution can't be done.

One possibility might be that an option be added to "set range" which 
stands for "temporary range set", e.g.,

set xrange [x_left:x_right] temp

or maybe

set xrange [x_left:x_right] replot

which would mean that the range settings in this command only apply to 
replot and when a new plot command comes along, the original ranges are 
used, not the "temp" or "replot" ones.  Also, with the new plot command, 
these "temp" or "replot" settings are changed to those ranges 
corresponding to "plot".

That would mean internally, gnuplot has

x_range_plot
x_range_replot

Any commands "replot" use the settings in x_range_replot.  Any commands 
"plot" use x_range_plot.  A "plot" command does x_range_replot = 
x_range_plot.  "set xrange [:] replot" does x_range_replot = [:].  "set 
xrange [:]" does x_range_replot = x_range_plot = [:].

Thus, the mouse zoom could do a

set xrange [:] replot
set yrange [:] replot
replot

and not disturb the overall settings.

>[... other problem...]
>  
>
>>strings would be shifted, the key would be in the wrong place.  The next 
>>two or three plots showed the same thing, getting progressively worse. 
>> The problem then corrected itself and things worked fine again.  I 
>>haven't been able to reproduce this.
>>    
>>
>
>Well, next time you come across this, 'save' the state of the broken plot
>then, before it disappears.
>

OK

Dan

Re: include gnuplot executables/sources in third-part application

[Hans-Bernhard B. <br...@ph...>]

On Thu, 13 May 2004, Luiz Eleno wrote:

[No quoted text here --- mail hit SF.net's QP encoding bug... please try
posting in plain ASCII, to avoid triggering that.]

You can do that. 

But you really should read the license for yourself. There's absolutely no
substitute for actually *reading* legal documents before subscribing to
them (which, by distributing wgnuplot binaries, you would be doing).

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Zoom peculiarities

[Hans-Bernhard B. <br...@ph...>]

On Wed, 12 May 2004, Daniel J Sebald wrote:

> Here is something odd in the latest CVS version.  In the "using.dem" 
> script, for the first plot, with the mouse active, zoom in on say a top 
> middle third of the data.  There will be some lines extending below the 
> bottom border.  The length of the lines seems to vary upon what area was 
> zoomed.  (That is, do this again and the line lengths may be shorter or 
> longer by random.)

'impulses' plots assume the plot has a baseline they can use.  Zooming may
break that assumption.  There have been problems like this with impulses
in the past.  So yes, this is a bug, but not an entirely unexpected one.

> 
> With the first plot still zoomed, go to the command line, hit return and 
> go to the second plot.  The second plot will be zoomed also.  (Should it 
> stay zoomed?)  In the window, unzoom the second plot by typing 'u'.  The 
> ranges don't seem to be very nice.  The image is small.  The second plot 
> script issues a
> 
> set xrange [1:8]
> 
> Is there a problem with setting the range when in zoomed mode?

No.  There's a more general problem in the way zooming, and especially the
'u'nzoom hotkey works.  The general problem is that mouse interactions
change the global state of gnuplot settings.  You can see that happening
by typing the '6' hotkey: each zooming operation modifies the global range
settings.

In scripts like our demos, where all settings not explicitly changed
between plots are assumed to keep the values from the previous plot
command, that will break massively.  Until we implement separate global
data sets for each plot, so the mousing code can work on a copy instead of
the single instance of all the settings we have, I don't think there's
much that can be done about that.

Workaround: don't zoom in demos; or if you do, remember to unzoom _before_
you proceed to the next plot. Using 'unzoom' on a different graph than the
one you zoomed on is IMHO begging for trouble.

[... other problem...]
> strings would be shifted, the key would be in the wrong place.  The next 
> two or three plots showed the same thing, getting progressively worse. 
>  The problem then corrected itself and things worked fine again.  I 
> haven't been able to reproduce this.

Well, next time you come across this, 'save' the state of the broken plot
then, before it disappears.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

include gnuplot executables/sources in third-part application

[Luiz E. <el...@mp...>]

Dear all,

Without going to the licenses and read it, I ask: Am I allowed to=20
include gnuplot 4.0 windows executables and/or sources in my open-source =

application? AFAIK octave does that, but it is better to ask, just in cas=
e.

I don't know if this is a relevant information , but at installation =20
time the user can choose not to install gnuplot, if he or she so desires.=


Best regards,
Luiz.

--=20
Luiz Eleno
Max-Planck-Institut f=FCr Eisenforschung
Max-Planck-Str. 1
D-40237 D=FCsseldorf
Tel.: +49-(0)211-67 92 481
Fax: +49-(0)211-67 92 537
el...@mp...

Zoom peculiarities

[Daniel J S. <dan...@ie...>]

Here is something odd in the latest CVS version.  In the "using.dem" 
script, for the first plot, with the mouse active, zoom in on say a top 
middle third of the data.  There will be some lines extending below the 
bottom border.  The length of the lines seems to vary upon what area was 
zoomed.  (That is, do this again and the line lengths may be shorter or 
longer by random.)

With the first plot still zoomed, go to the command line, hit return and 
go to the second plot.  The second plot will be zoomed also.  (Should it 
stay zoomed?)  In the window, unzoom the second plot by typing 'u'.  The 
ranges don't seem to be very nice.  The image is small.  The second plot 
script issues a

set xrange [1:8]

Is there a problem with setting the range when in zoomed mode?

Dan

PS:  This next observation comes with a caveat.  I was working on some 
image code at the time so it may have been mea culpa.  But the image 
stuff has been fairly robust lately so I thought I'd mention it. 
 Anyway, I was resizing a window for a plot once and objects started to 
appear in strange random places on the plot.  For example, the text 
strings would be shifted, the key would be in the wrong place.  The next 
two or three plots showed the same thing, getting progressively worse. 
 The problem then corrected itself and things worked fine again.  I 
haven't been able to reproduce this.  But in all my times of messing 
about with Gnuplot I've not seen (or inadvertently caused) X11 behavior 
like that.  So, just a heads up for now.

mono png

[Dan J. <ji...@ji...>]

echo "set terminal png;plot '/tmp/t'"|gnuplot -mono
does not make a mono png. Oh, it is an x option... OK, at least make
an error message.

Indeed, on the "png (NEW)" info page, we find no simple way to make
mono png's.  We will have to use a post processor like ImageMagick.

You ought to put cross references in the Label, Title, etc. Info
pages, to "Key", as I searched for hours before finally figuring out
how to turn the filename off in the output.

gnuplot 3.8k patchlevel 1

Plotting with linespoints

[M. <ma...@im...>]

Hi!

Is it possible to make a graph from a datafile with "linespoints" where the line
is drawn for every data-point and the points are drawn for every nth datapoint?
If not, then this should be implemented... :D

Kind Regards,
Søren Madsen

Re: Making demo programs more evident...

[Petr M. <mi...@ph...>]

> > $ rpm -q gnuplot
> > gnuplot-3.7.3-106
> > gnuplot-4.0.0-1
>
>
> > The former by SUSE, the other by
> > 	checkinstall make install-strip
>
> Well, suffice it to say that if you make a less complete RPM than SuSE,
> the blame for that is entirely yours.

I don't do RPM for distribution; I do it for myself to be able to uninstall
the package easily, from my own system. That's "checkinstall" good for.

Forget RPM and consider it as "make install" with a later possibility of
"make uninstall".


> > Now I want all goes into a useful directory there. Why not
> >
> > 	$HOME/usr/share/doc/gnuplot-4.0.0/
>
> Because it would break things for distributors, who want to build and
> install using '--prefix=/usr' and have the demos and other docs under
> /usr/share/doc/packages/gnuplot, not under /usr/share/doc/gnuplot-4.0.0

Distributors can put stuff where they want. Here, we speak about
making/instaling current gnuplot for yourself, not how distributors should
make their RPM.

Moreover, on a experimental workstation with HPUX, there is no RPM
distributor.

> I.e. we should leave the $(prefix)/share/doc directory alone.  If at all,
> it'ld have to be either
>
> 	$(prefix)/share/gnuplot/4.0
> or	$(prefix)/share/gnuplot-4.0
>
> I would prefer the former, because it's more in parallel with our
> installation directory for gnuplot_x11,
> $(exec_prefix)/libexec/gnuplot/4.0/

If someone makes such a Makefile target to be close to gnuplot 4.0.0
binaries zips for OS/2 or Windows, that'll be great.


---
PM

Re: gnuplot audio driver?

[Hans-Bernhard B. <br...@ph...>]

On Mon, 10 May 2004, Allin Cottrell wrote:

> I can imagine something like the following: a "graph file" takes the
> form of a "preamble" which announces the units and ranges of the axes,
> followed by a sonic representation of the data series (e.g. rising
> pitch for rising curve).  The technologies needed for this are (a)
> speech synthesis and (b) "data sonification" (I think MIDI would do
> well for the latter).

Ah.  Well, in that case, I hereby propose that this driver be called "set
terminal Anthem", in reference to Douglas Adams' novel "Dirk Gently's
Holistic Detective Agency".  Including a proper dedication of the work in
the source code, or even in the docs.  ;-)

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Making demo programs more evident...

[Hans-Bernhard B. <br...@ph...>]

On Mon, 10 May 2004, Petr Mikulik wrote:

> Are you sure? I have two.
> 
> $ rpm -q gnuplot
> gnuplot-3.7.3-106
> gnuplot-4.0.0-1


> The former by SUSE, the other by
> 	checkinstall make install-strip

Well, suffice it to say that if you make a less complete RPM than SuSE,
the blame for that is entirely yours.

> No, they don't know, and no, they won't read it -- or stop reading before
> "how to install demos".

I strictly refuse to worry about people who don't read READMEs and follow
instructions contained in them.  If they don't bother, neither will I.

> Look at other software packages -- their "make install" installs more docs,
> faqs, demos. Why should gnuplot not do this?


> 	./configure --prefix=$HOME/usr
> 
> Now I want all goes into a useful directory there. Why not
> 
> 	$HOME/usr/share/doc/gnuplot-4.0.0/

Because it would break things for distributors, who want to build and 
install using '--prefix=/usr' and have the demos and other docs under
/usr/share/doc/packages/gnuplot, not under /usr/share/doc/gnuplot-4.0.0

I.e. we should leave the $(prefix)/share/doc directory alone.  If at all,
it'ld have to be either

	$(prefix)/share/gnuplot/4.0
or	$(prefix)/share/gnuplot-4.0

I would prefer the former, because it's more in parallel with our
installation directory for gnuplot_x11,
$(exec_prefix)/libexec/gnuplot/4.0/

> > copy of the demos into the online help, odds are distributors will manage
> > to break it.  But it'll likely be us who get the complaints about it.
> 
> Don't put the exact pointer, but say "see gnuplot doc installed on your
> system".

Somehow I'm not convinced that this phrase would help to reduce the number
of questions about where they might be...


> If every application of those 1466 wastes 700 KB as gnuplot, it is 1 GB of
> wasted HD. That's not negligable.

*If*.  But they don't, and they shouldn't.  There is a difference between
a distributor-built, supported RPM (or DEB) package, and locally built and
installed programs, see.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: gnuplot audio driver?

[Hans-Bernhard B. <br...@ph...>]

On Sun, 9 May 2004, Allin Cottrell wrote:

> I wonder if anyone has experimented with an audio driver of any sort
> for gnuplot?

I'm not quite sure I understand what you mean.  An audio *file* driver, or
a direct-to-hardware device driver?  The former should be a lot easier to
do.  Table terminal output should be reasonably easy to convert into an
audio file format of your choosing.

I don't quite see this as something we should put into gnuplot itself.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Making demo programs more evident...

[Hans-Bernhard B. <br...@ph...>]

On Sun, 9 May 2004, Daniel J Sebald wrote:

> I think the additional method requiring installing demos isn't so bad. 
>  That is, a separate "make install-demos" which would require some 
> interaction (i.e., specifying the exact directory, the "make 
> install-demos" would automagically define GNUPLOT_LIB and add the demo 
> directory to it) 

But 'make install' can't do that.  Modifying the user's environment
variables is way out of scope of a simple program installation.  The best
you could do would be to display a comment as part of running 'make
install' that reminds the user this should be done.  Or make that note
part of 'help demo' (to be written).

> would be something only run by the distributors. 

Distributors already install the demos, generally.  They're not really the
parties we're worried about here.  That'd rather be the persons building
and installing gnuplot from sources.

> >It might make sense to mention install-strip in the INSTALL document.
> >
> 
> I assume that non-stripped is the default because developers want to do 
> debugging?  

Not quite --- we would have the sources and a non-installed, un-stripped
binary for that.  The original reasoning goes back to Mr. Stallman
himself, who insists on having at least minimal debugging capabilities in
installed programs.  I.e. if a user reports a strange problem, on hardware
we have no access to ourselves, the default un-stripped installation
allows us to walk him through a debugger session and show us a backtrace.

It's all written down somewhere in the GNU Coding Standards, I think.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Making demo programs more evident...

[Petr M. <mi...@ph...>]

> I dislike having stripped executables, because if something goes
> wrong you get essentially zero information to help you report or
> fix the problem.  The small increase in disk space is a minor price
> to pay for having debuggable programs.

I don't remember very much of such information being posted regularly on the
gnuplot mailing/news lists. It is OK for developers, but for regular users,
not (especially for final release).

--
PM

Re: Making demo programs more evident...

[Petr M. <mi...@ph...>]

> > Hmm on "unix" .. "make install" does not install demos, so there is not
> > "properly" installed unix.
>
> As far as I'm aware, none of our makefiles installs the demos anywhere.
> Nor did any of them, ever.


Yes, and that's what I always complain about: there is no "make install all"
that would do automatically such an install as I packaged for OS/2 and
Windows packages -- ie including all docs, demos, INSTALL and README files.

> > Using a rpm package for gnuplot ... turns you to demos for an old
> > gnuplot.
>
> Huh? That only applies if you look at an old, now outdated RPM, obviously.
> There'll be only *one* binary RPM of gnuplot installed in any given box.

Are you sure? I have two.

$ rpm -q gnuplot
gnuplot-3.7.3-106
gnuplot-4.0.0-1

The former by SUSE, the other by
	checkinstall make install-strip

Of course, gnuplot's own "make install-strip" sucks for the above reasons
(no docs, no demos, no FAQ, ...).


> > INSTALL writes ./configure does not want to decide where to put demos --
> > why not?
>
> INSTALL says so, and it's written in there for said "ordinary people" to
> see.  So they'll know there are demos they may want to install, at a place
> of their choosing.

No, they don't know, and no, they won't read it -- or stop reading before
"how to install demos".

I don't understand why you don't want to support ordinary people who wish to
do
	make install

and have installed really everything what gnuplot offers.

Look at other software packages -- their "make install" installs more docs,
faqs, demos. Why should gnuplot not do this?

Actually -- if we don't let install all, we have more troubles answering
FAQs...


> > /usr/local/share/gnuplot/... gnuplot is already writing there, why not use
> > it for demo?
>
> That would be the right place for them to go for a non-RPM local
> installation from sources.  I.e. if we make a "install-demos" target, or
> have the default 'install' put them up anywhere, $(pkgdatadir)/demo is
> where that'll be.
>
> But it's not the place the existing binary packages made by third parties
> put them.  SuSE Linux, e.g., puts such files below
> /usr/share/docs/packages/<name>, not /usr/share/<package>, and they may
> prefer to keep it that way.  But since there's no
> /usr/local/share/docs/packages in a Linux system, we can't easily
> duplicate that, and probably we shouldn't.

Look this way: I want to install new gnuplot for me and just me, on a unix
box. Thus I do:

	./configure --prefix=$HOME/usr

Now I want all goes into a useful directory there. Why not

	$HOME/usr/share/doc/gnuplot-4.0.0/
and thus:
	$HOME/usr/share/doc/gnuplot-4.0.0/ with gnuplot.pdf, ...
	$HOME/usr/share/doc/gnuplot-4.0.0/psdocs
	$HOME/usr/share/doc/gnuplot-4.0.0/demo


Similarly,

        ./configure --prefix=/usr/local
would do
       $HOME/usr/share/doc/gnuplot-4.0.0/  with gnuplot.pdf, tutorial.pdf,
				gpcard.pdf, FAQ
       $HOME/usr/share/doc/gnuplot-4.0.0/psdocs
       $HOME/usr/share/doc/gnuplot-4.0.0/demo


What about accepting this scheme?


> And remember that as soon as we put a pointer to the locally installed
> copy of the demos into the online help, odds are distributors will manage
> to break it.  But it'll likely be us who get the complaints about it.

Don't put the exact pointer, but say "see gnuplot doc installed on your
system".


> Those people who care, know.  Those who build RPMs at distributors
> included.

$ rpm -qa | wc -l
   1464

If every application of those 1466 wastes 700 KB as gnuplot, it is 1 GB of
wasted HD. That's not negligable.


> OTOH, HD space is less than 0.01 USD or EUR per MB these days...

But:
1. You cannot easily change hard disk in your notebook.
2. You cannot change/add hard disk in computer of your company.
3. You cannot add new hard disk for whichever other hardware reason.

---
PM

emf.trm update

[Stephane B. <gn...@co...>]

Hi

    As you may or you may not have noticed, generated EMF files don't
display anymore on windows... for those who applied the last MS Security
patch KB538732=20
(http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;835732)!!!  In
fact, while attempting to correct a buffer overflow security breach in
GDI32.dll, MS introduced new bugs... GNUPlot, Adobe products, and some
other products are then concerned.

    So here my answer to MS idiots : a new version of emf.trm ;-)

    what's new :
- FIX : EMREXTCREATEFONTINDIRECTW is now 332 bytes long instead of 104=20
since they want the full struct declaration
- CHG : EMREXTTEXTOUTA is used instead of EMREXTTEXTOUTW since some
librairies don't recognize the unicode version (as stated in a mail with
subject "emf woes")
- FIX : EMREXTTEXTOUTA is now writing the **optional**
intercharacter spacing array (but we still doesn't use it because we
can't use it),

This new version should now work with or without the MS patch applied on
the computer...

Have a nice day

--=20
St=E9phane BARBARAY.

Re: gnuplot audio driver?

[Daniel J S. <dan...@ie...>]

Allin Cottrell wrote:

>I wonder if anyone has experimented with an audio driver of any sort
>for gnuplot?
>
>I ask because I face the interesting challenge, this coming Fall, of
>teaching a data analysis class that will include a blind student.
>
>Allin Cottrell
>

There are the Octave audio functions.  However, the documentation on a 
few of them is what I suspected (end of first paragraph below).  A 
fairly standard audio card might (might!) work with the existing Octave 
version.  Recording properly is probably more unlikely.

=====

   The following functions for audio I/O require special A/D hardware
and operating system support.  It is assumed that audio data in linear
encoding can be played and recorded by reading from and writing to
`/dev/dsp', and that similarly `/dev/audio' is used for mu-law
encoding.  These file names are system-dependent.  Improvements so that
these functions will work without modification on a wide variety of
hardware are welcome.

 - Function File:  playaudio (NAME, EXT)
 - Function File:  playaudio (X)
     Plays the audio file `NAME.EXT' or the audio data stored in the
     vector X.

 - Function File:  record (SEC, SAMPLING_RATE)
     Records SEC seconds of audio input into the vector X.  The default
     value for SAMPLING_RATE is 8000 samples per second, or 8kHz.  The
     program waits until the user types <RET> and then immediately
     starts to record.

 - Function File: setaudio ([W_TYPE [, VALUE]])
     executes the shell command `mixer [W_TYPE [, VALUE]]'

Re: An observation in animate demo.

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>On Sunday 09 May 2004 11:12 pm, Daniel J Sebald wrote:
>  
>
>>Ethan A Merritt wrote:
>>
>>    
>>
>>>I tentatively propose to modify the time delay to be
>>>#ifdef HAVE_USLEEP
>>>	usleep(100);
>>>#else
>>>	sleep(1);
>>>#endif
>>>      
>>>
>>Not completely comfortable with that for the simple fact that it is
>>increasing the likelihood of a discarded character.
>>    
>>
>
>No, I think I haven't explained it well enough.  You will not lose
>a character until waitforinput() gives up and leaves the loop
>entirely. It is still possible to loop as many times as you like
>before giving up.   Total wait time = time per loop X # of iterations.
>If you still have no response from the X server after several
>seconds, I think losing a character is the smaller part of your
>problem at that point.
>
>If things are functioning properly, then a loop like the one in
>animate.dem will only go through the waitforinput() loop once
>per replot even if there is unexpected terminal input. So making
>the per-loop delay shorter should take care of the problem.
>

Oh, I see.  The delay is simply to prevent the consumption of all the 
CPU cycles, not to solve the character being discarded.  That problem 
was solved with the original wait protocol.  Yeah, the #ifdef 
HAVE_USLEEP should do.

Dan

Re: An observation in animate demo.

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 09 May 2004 11:12 pm, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
>
> >I tentatively propose to modify the time delay to be
> >#ifdef HAVE_USLEEP
> >	usleep(100);
> >#else
> >	sleep(1);
> >#endif
>
> Not completely comfortable with that for the simple fact that it is
> increasing the likelihood of a discarded character.

No, I think I haven't explained it well enough.  You will not lose
a character until waitforinput() gives up and leaves the loop
entirely. It is still possible to loop as many times as you like
before giving up.   Total wait time = time per loop X # of iterations.
If you still have no response from the X server after several
seconds, I think losing a character is the smaller part of your
problem at that point.

If things are functioning properly, then a loop like the one in
animate.dem will only go through the waitforinput() loop once
per replot even if there is unexpected terminal input. So making
the per-loop delay shorter should take care of the problem.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: gnuplot audio driver?

[Daniel J S. <dan...@ie...>]

Allin Cottrell wrote:

>I wonder if anyone has experimented with an audio driver of any sort
>for gnuplot?
>
>I ask because I face the interesting challenge, this coming Fall, of
>teaching a data analysis class that will include a blind student.
>
>Allin Cottrell
>

Something I've never thought of, but interesting idea.  Are you thinking 
of combining plotted waveforms with a capability to listen to them, as 
in a speech processing scenario?

Of course, the problem is the long running history of PC's and various 
systems not having a standard audio interface.  Perhaps that has changed 
in the recent past, but judging from the last time I went though buying 
a computer it didn't seem like it.

Dan

Re: An observation in animate demo.

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:

>On Sunday 09 May 2004 01:27 pm, Hans-Bernhard Broeker wrote:
>  
>
>>On Fri, 7 May 2004, Daniel J Sebald wrote:
>>    
>>
>>>gnuplot> load 'animate.dem'
>>>      
>>>
>
>  
>
>>> But if I hit return once again in the middle of the demo it
>>>will slow down its redraw rate significantly.
>>>      
>>>
>>I think that's the same old X11 multiple-stream handling problem again.
>>    
>>
>
>Sort of.  I added a time delay deliberately to handle a different
>problem, but this is an example of where it imposes a penalty.
>Let me explain what is going on, and you all can speak up as
>to how you want it handled.
>
>The issue is this.
>
>1) When a plot (or replot) is started, the x11 driver sends a query to
>the X-server asking it some basic information like how big is the
>window and what size is the font being used.  This allows much better
>plot layout. Because of this the x11 layout is much nicer in version 4,
>and the information is needed to support enhanced text mode for x11.
>
>2) X11_waitforinput() now waits for the X-server to reply.
>
>3) If terminal input comes in while it is waiting, X11_waitforinput() wakes
>up, notices that it isn't ready to handle new terminal input yet, and then
>loops back to the loop to wait again for the X-server to reply.
>
>4) Problem #1 is that we don't want to read the terminal input at this
>point because that would cause characters to be lost.  That's
>what it used to do, and there were lots of complaints.
>
>5) Problem #2 is that once there is terminal input pending, the select()
>call returns immediately every time through the loop, so we sit there
>burning CPU cycles like mad until the X-server finally responds.
>There were complaints about this also.
>
>6) So as a compromise, I put in a 1 second time delay before going back
>to the top of the loop and the select() call.  
>

Well, actually, this makes the likelihood of a character loss much 
smaller.  There could still be a problem if for some reason the x11 
queries take more than a second, say the system is off doing a lengthy 
hard drive access.  Is this correct?

>Digression: I also added a maximum number of times through the loop,
>so that if the X-server never responds (should only happen in the case
>of a serious error, perhaps  DISPLAY set to an incorrect value) there
>is still a maximum time elapsed before gnuplot returns to accepting
>terminal input.  Even more recently I figured out how to allow ctrl-C to
>interrupt in the case of a jammed X-server, so this maximum loop count
>is no longer strictly necessary but it doesn't by itself hurt anything.
>
>7) In the case of a real X-11 error, like a bad network connection, the
>1 second delay is a small price to pay for handling a bad connection
>without locking up the CPU.  In the case of a loop, however, even with
>a fully responsive X-server the unexpected terminal input causes a
>1 second delay every time through the loop. I agree this is bad.
>
>Possible fixes:
>
>Make the time delay much smaller.  On platforms with usleep()
>it could be some number of microseconds rather than a full second.
>As I recall, I originally I had usleep(100) but I switched to sleep(1)
>when I realized that not all platforms provide usleep().
>
 >

>Don't send the font+window size query if mousing is disabled.
>Then in the case of an animation loop you could just disable the
>mouse before entering the loop, and re-enable it afterwards if
>needed.   I don't like this because if your original plot has 
>mousing disabled, you will never get the info about window or
>font size.  OTOH perhaps replot could handle this differently than
>plot (I'd have to look to see whether X11_waitforinput() can
>tell the difference). This would actually speed up the animation loop,
>since even if the X-server is responding normally the query/response
>cycle is kind of slow compared to everything else.
>
 >

>Introduce a new command to toggle the query/response feedback.
>The internal mechanism is already in place, because some time 
>back I added this as a command line option   'gnuplot -nofeedback'
>in order to allow people with problems to turn it off altogether.
>I don't like this because it's a command that would be specific to
>X11, and would just clutter up the command set.
>

I know developers are against this.  But the issue of being X11 specific 
doesn't bother me.  I'd say trust your instinct for what to do, but wait 
if or until you have an nice solution in mind for which you won't mind 
breaking the current set up.

>I tentatively propose to modify the time delay to be
>#ifdef HAVE_USLEEP
>	usleep(100);
>#else
>	sleep(1);
>#endif
>

Not completely comfortable with that for the simple fact that it is 
increasing the likelihood of a discarded character.  However, at this 
point coming off the 4.0 release I think this would be a reasonable 
solution and then maybe put mouse mods on hold for a while because other 
things might be worth adding and testing.

Am I right in thinking that now that the developers have put a lot of 
work into a stable 4.0 after a long long duration of developments, it 
might be easier to get successive versions ready?  But not too often.  
:-)  So perhaps some smaller changes would be in order.  Coming up with 
a target date for a next release candidate, say 1 year from now, might 
be good.  Also, establishing and prioritizing some general goals for 
that release would help.  (I could offer some if people want to start 
discussing that.)

>I am open to feedback about whether 'unset mouse' should
>disable the size+font query altogether in the case of a replot,
>or the question of having an explicit command to disable it.
>

Eh.  A command the user has to know when and how to apply and it may 
behave differently on different platforms?  Nah.

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

gnuplot audio driver?

[Allin C. <cot...@wf...>]

I wonder if anyone has experimented with an audio driver of any sort
for gnuplot?

I ask because I face the interesting challenge, this coming Fall, of
teaching a data analysis class that will include a blind student.

Allin Cottrell

Re: An observation in animate demo.

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 09 May 2004 01:27 pm, Hans-Bernhard Broeker wrote:
> On Fri, 7 May 2004, Daniel J Sebald wrote:
>> gnuplot> load 'animate.dem'

>>  But if I hit return once again in the middle of the demo it
>> will slow down its redraw rate significantly.
>
> I think that's the same old X11 multiple-stream handling problem again.

Sort of.  I added a time delay deliberately to handle a different
problem, but this is an example of where it imposes a penalty.
Let me explain what is going on, and you all can speak up as
to how you want it handled.

The issue is this.

1) When a plot (or replot) is started, the x11 driver sends a query to
the X-server asking it some basic information like how big is the
window and what size is the font being used.  This allows much better
plot layout. Because of this the x11 layout is much nicer in version 4,
and the information is needed to support enhanced text mode for x11.

2) X11_waitforinput() now waits for the X-server to reply.

3) If terminal input comes in while it is waiting, X11_waitforinput() wakes
up, notices that it isn't ready to handle new terminal input yet, and then
loops back to the loop to wait again for the X-server to reply.

4) Problem #1 is that we don't want to read the terminal input at this
point because that would cause characters to be lost.  That's
what it used to do, and there were lots of complaints.

5) Problem #2 is that once there is terminal input pending, the select()
call returns immediately every time through the loop, so we sit there
burning CPU cycles like mad until the X-server finally responds.
There were complaints about this also.

6) So as a compromise, I put in a 1 second time delay before going back
to the top of the loop and the select() call.  

Digression: I also added a maximum number of times through the loop,
so that if the X-server never responds (should only happen in the case
of a serious error, perhaps  DISPLAY set to an incorrect value) there
is still a maximum time elapsed before gnuplot returns to accepting
terminal input.  Even more recently I figured out how to allow ctrl-C to
interrupt in the case of a jammed X-server, so this maximum loop count
is no longer strictly necessary but it doesn't by itself hurt anything.

7) In the case of a real X-11 error, like a bad network connection, the
1 second delay is a small price to pay for handling a bad connection
without locking up the CPU.  In the case of a loop, however, even with
a fully responsive X-server the unexpected terminal input causes a
1 second delay every time through the loop. I agree this is bad.

Possible fixes:

Make the time delay much smaller.  On platforms with usleep()
it could be some number of microseconds rather than a full second.
As I recall, I originally I had usleep(100) but I switched to sleep(1)
when I realized that not all platforms provide usleep().

Don't send the font+window size query if mousing is disabled.
Then in the case of an animation loop you could just disable the
mouse before entering the loop, and re-enable it afterwards if
needed.   I don't like this because if your original plot has 
mousing disabled, you will never get the info about window or
font size.  OTOH perhaps replot could handle this differently than
plot (I'd have to look to see whether X11_waitforinput() can
tell the difference). This would actually speed up the animation loop,
since even if the X-server is responding normally the query/response
cycle is kind of slow compared to everything else.

Introduce a new command to toggle the query/response feedback.
The internal mechanism is already in place, because some time 
back I added this as a command line option   'gnuplot -nofeedback'
in order to allow people with problems to turn it off altogether.
I don't like this because it's a command that would be specific to
X11, and would just clutter up the command set.

I tentatively propose to modify the time delay to be
#ifdef HAVE_USLEEP
	usleep(100);
#else
	sleep(1);
#endif

I am open to feedback about whether 'unset mouse' should
disable the size+font query altogether in the case of a replot,
or the question of having an explicit command to disable it.

	Ethan


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle