Tom,
Okay, so by switching from the 'nv' driver supplied with redhat to the 'nvidia' driver supplied by Nvidia (on a gforce4-somethingorother) I no longer get that weird crash.
but...
process exited".
array name actually caused my system to hang.
Other than that, looks great. :)
David __ _ _ _ _ __ ___ _ ___ __ _ _ _ ____ __ Music wants to be free http://sintheta.org
Tom Schouten wrote:
hi all,
announcing the first release of wvvw, a minimalistic array viewer for pd, supporting selection and navigation in an external window.
more info and tarball at
http://zwizwa.fartit.com/pd/wvvw/
linux only atm, but should be cross platform (uses only pthread, gl and glut)
enjoy,
tom
Hi all
first off, thanks Tom for a terrific new toy!
now for David's comments...
David NG McCallum wrote:
Okay, so by switching from the 'nv' driver supplied with redhat to the 'nvidia' driver supplied by Nvidia (on a gforce4-somethingorother) I no longer get that weird crash.
Looked like you didn't have any/good OpenGL support with your other drivers. You must not run GEM or PDP much, eh? ;-) Try "glxgears" with each set of drivers loaded to see the performance difference.
- closing the window with the mouse causes pd to quit with "pd_gui: pd
process exited".
I can back this up, but there is a good reason for it. See below...
- deleting the wvvw object leaves the wvvw window still in existence
Also true here.
The reason is that the window is called into creation when the wvvw library is loaded, not when the object is created. This differs a bit from the GEM/PDP paradigm, where the display can be created and destroyed, and takes some getting used to, but I wouldn't consider it a bug.
Interestingly enough, multiple objects [reading different arrays] make multiple tracks in the window, which are individually selectable. Super-cool!
- and once (hasn't been replicated) instantiating wvvw with an unknown
array name actually caused my system to hang.
Hasn't happened to me yet....
d.
Thanks again for a terrific toy, Tom.
Just a few ideas which might make it even cooler. Embrace or disregard them as time allows...
one master window.
Ability to nest seperate windows in patches, or even graph-on-parent.
Ability to label each track in the window(s?), either statically by
array-name, or dynamically with the pathname of the file loaded [from soundfiler]
like Frank could use it in their end-user-oriented patches such as the RRADical patches.
About the keybindings:
I was just playing with the keybindings for getting the array position and length of the mouse selection from the window, and I find it wonderful. It was almost effortless to figure out how to assign a different keybinding to each track in the window (via [route x], [route y], [route q], etc....] I am curious, however, why I cannot see the contents of the packed message coming directly out of the [route] object. Common sense would tell me that the output would be a compound messsage of position and length, but a [print] object still only gives me the key event, and not the numbers. Why is that?
best, d.
Thanks again for a terrific toy, Tom.
my pleasure.
Just a few ideas which might make it even cooler. Embrace or disregard them as time allows...
- Ability to make multiple instances of the viewing window instead of one
master window.
ah, the 'proper' approach :) will have to wait until some threading bugs are ironed out.
- Ability to nest seperate windows in patches, or even graph-on-parent.
tis would be very cool, indeed. though i don't know how to do that. would require 1.
- Ability to label each track in the window(s?), either statically by
array-name, or dynamically with the pathname of the file loaded [from soundfiler]
fonts. font libs. maybe later :)
- Of course, eventual multiplatform support would be nice, so people like
Frank could use it in their end-user-oriented patches such as the RRADical patches.
this should be just a makefile (execept maybe for the kill(getpid(), SIGTRAP) in the ASSERT macro, which is optional)
About the keybindings:
I was just playing with the keybindings for getting the array position and length of the mouse selection from the window, and I find it wonderful. It was almost effortless to figure out how to assign a different keybinding to each track in the window (via [route x], [route y], [route q], etc....] I am curious, however, why I cannot see the contents of the packed message coming directly out of the [route] object. Common sense would tell me that the output would be a compound messsage of position and length, but a [print] object still only gives me the key event, and not the numbers. Why is that?
well, that's strange. pre-route i get x <start> <length> post-route (the x outlet) i get <start> <length>, just as expected.
is this what you mean?
cheers tom
Tom Schouten wrote:
a [print] object still only gives me the key event, and not the numbers. Why is that?
well, that's strange. pre-route i get x <start> <length> post-route (the x outlet) i get <start> <length>, just as expected.
is this what you mean?
Weeeelllll.. it does this now. I can't explain why it didn't before. User error could be a culprit... ;-)
best, d.
hi david,
- closing the window with the mouse causes pd to quit with "pd_gui: pd
process exited".
bug.
- deleting the wvvw object leaves the wvvw window still in existence
that's a feature :) there's only one window, which (should) live as long as your pd session, but it can host multiple wave views. (if you use multiple wvvw objects)
- and once (hasn't been replicated) instantiating wvvw with an unknown array
name actually caused my system to hang.
ouch. nasty bug.
Other than that, looks great. :)
thanks :)
btw, if you have a recent nvidia card, you can use this to set full screen anti-aliasing:
export __GL_FSAA_MODE=5