Re: Problems running example audio_fft.py

I suspect that most of our wxPython performance problems could be
fixed if someone were to implement a native C++ plotting widget for
wxWidgets and then provide the appropriate wxPython binding for it.

I was also already looking into this and came across wxCode’s wxplot
which is taken from the plplot library. I compiled wxwidgets and
wxplot on my mac and it compliled without problems. I also saw the
xcode component wxplotctl, but that did not compile correctly on my
mac or linux. Does any one have any experience with these? Any further
resources to look into? Or would a ground up plotting widget be
necessary? I would be interested in looking further into these
possibilities.

Josh

I also saw the wxcode component wxplotctl, but that did not compile
correctly on my mac or linux.

I stand corrected: I was trying to install the wxcode componenets
wrong. In order to install the wxcode components you need to go into
the src dir of the component and then run make. The readme was not
clear about this since you can also run make from the components top
directory.

Josh

I stand corrected: I was trying to install the wxcode componenets
wrong. In order to install the wxcode components you need to go into
the src dir of the component and then run make.
Note: This only held for linux. On Mac, wxthings dies (wxthings is
needed for wxplotctrl) from an error due to missing headers that are
not taken into consideration in the mac build of wxwidgets, therefore
I couldn’t get wxplotctrl up.

On the other hand, I got plplot running on my mac and seems promising
as an alternative since it has an aquaterm driver (as well as many
others) and based on a simple example, x17, can plot in real time,
although it would need some improvements. plplot has straight from the
box bindings for c, c++ and python. Any one have any ideas?

Josh

On Wed, Oct 25, 2006 at 10:06:07AM +0200, Josh Jennings wrote:

necessary? I would be interested in looking further into these
possibilities.

Josh

I don’t have any experience with those.

I was thinking along the lines of a relatively simple widget. No data
dependent autoscaling. Just tell it the number of grid lines to draw
in X and Y, have the internal coordinate system of the widget be
scaled from (0,0) to (1,1) (resizing the widget would adjust the
internal scaling factor); provide a 3x3 transform matrix similar to
open GL’s 4x4 matrix, then provide primitives for drawing polylines,
points, etc that are run through the tranform matrix.

That way the high level interface allows us to pass arrays of points
and the “right thing happens” quickly.

We may also want to allow the axes to be drawn and labeled in a
persistent way – only redrawn when something changes – instead of
every time. We could blit them prior to drawing in the data.

Might be worth looking at just using an opengl canvas in wxpython.
That may get us what we’re looking for. Not sure.

If you could find some time to look at this, that would be great!

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs