Re: [PD] ARToolkit and libqrencode for Gem
Try compiling it and post the errors here. .hc On May 24, 2008, at 3:36 AM, palmieri, ricardo wrote: hans have some tip to me start to compile the gem from pd-extended source with artoolkit? the artoolkit lib is working in macmini intel and powerbookg4. lets put it to work? palm 2008/5/23 Hans-Christoph Steiner [EMAIL PROTECTED]: It is included, but: error: [pix_artoolkit]: compiled without ARToolKit support! ... you might be able to track this down from the Find menu. .hvc On May 23, 2008, at 11:23 PM, Jack wrote: Why ? [pix_artoolkit] with pd-extended is not enough ? ++ Jack Le 23 mai 08 à 21:57, palmieri, ricardo a écrit : hi guys. somebody know some tutorial to compile gem with artoolkit object? i having a lot of doubts doing it. in really im having trouble in create a greate ./configure line, with the right prefix and libs. somebody can help me? im using pd-extended 0.39.3 and macmini with mac osx palmieri 2008/3/12 IOhannes m zmoelnig [EMAIL PROTECTED]: Hans-Christoph Steiner wrote: On Mar 11, 2008, at 1:59 PM, IOhannes m zmoelnig wrote: Hans-Christoph Steiner wrote: The other is pix_artoolkit, which is based on ARToolkit, which is a type of code to stick on things that you can then track in 3D space using Gem. well, at least his one has been backported to Gem in late 2006. people seem to not know this. What would be the best way to include this into Gem i tried to say: pix_artoolkit is included in Gem for more than a year. and/or Pd-extended, if it isn't already? [pix_artoolkit] is disabled by default. you need to have artoolkit installed and might have to set the --with-artoolkit-includes and --with-artoolkit-libs to configure accordingly. fmgasd. IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ricardo palmieri # 1185833173 [palm.estudiolivre.org] [skype:palmieriricardo] [jabber: [EMAIL PROTECTED] [msn: [EMAIL PROTECTED] [linux user # 392484] ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list - --- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin -- ricardo palmieri # 1185833173 [palm.estudiolivre.org] [skype:palmieriricardo] [jabber: [EMAIL PROTECTED] [msn: [EMAIL PROTECTED] [linux user # 392484] Mistrust authority - promote decentralization. - the hacker ethic ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [GEM] pix_write option for rendering a texture only
Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. The only *multiplatform* solution I'm thinking about is rendering the framebuffer into tiff files, cropping and transforming them to a lighter file format with imagemagicks controlled by a script file loaded with [popen], for having my texture rendered into a decent quality, that's quite complicated. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? Many thanks if you have a simple answer or another solution. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
hello, unless i misunderstand, what you describe is currently working. gemhead 99 | pix_write will capture in a file what you can see in the gem windows. cyrille Patrice Colet a écrit : Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. The only *multiplatform* solution I'm thinking about is rendering the framebuffer into tiff files, cropping and transforming them to a lighter file format with imagemagicks controlled by a script file loaded with [popen], for having my texture rendered into a decent quality, that's quite complicated. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? Many thanks if you have a simple answer or another solution. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
I would like rather something like this [gemhead] | [pix_video] | [pix_crop] | [rectangle 4 1.5] | [pix_write] to write in a file what I see into the rectangle only. it currently work with [pix_record] cyrille henry a écrit : hello, unless i misunderstand, what you describe is currently working. gemhead 99 | pix_write will capture in a file what you can see in the gem windows. cyrille Patrice Colet a écrit : Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. The only *multiplatform* solution I'm thinking about is rendering the framebuffer into tiff files, cropping and transforming them to a lighter file format with imagemagicks controlled by a script file loaded with [popen], for having my texture rendered into a decent quality, that's quite complicated. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? Many thanks if you have a simple answer or another solution. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
ok, what about : [gemhead] | [gemframebuffer) | [pix_video] | [pix_crop] | [square 4] and: [gemhead] | [pix_texture] | [rectangle 4 1.5] with a link from gemframbuffer right outlet to pix_texture right inlet you can render whatever you wish to a texture, and using this texture on different rectangles. why do you want to write them somewhere? cyrille Patrice Colet a écrit : I would like rather something like this [gemhead] | [pix_video] | [pix_crop] | [rectangle 4 1.5] | [pix_write] to write in a file what I see into the rectangle only. it currently work with [pix_record] cyrille henry a écrit : hello, unless i misunderstand, what you describe is currently working. gemhead 99 | pix_write will capture in a file what you can see in the gem windows. cyrille Patrice Colet a écrit : Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. The only *multiplatform* solution I'm thinking about is rendering the framebuffer into tiff files, cropping and transforming them to a lighter file format with imagemagicks controlled by a script file loaded with [popen], for having my texture rendered into a decent quality, that's quite complicated. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? Many thanks if you have a simple answer or another solution. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
hi cyrille, cyrille henry a écrit : ok, what about : [gemhead] | [gemframebuffer) | [pix_video] | [pix_crop] | [square 4] and: [gemhead] | [pix_texture] | [rectangle 4 1.5] with a link from gemframbuffer right outlet to pix_texture right inlet you can render whatever you wish to a texture, and using this texture on different rectangles. why do you want to write them somewhere? This is very interesting and I would have been glad to do this on another application but this isn't really what I'm looking for, let me explain why... I'm building an application where gemwin is always in fullscreen mode (for an exposition), there is no keyboard, no mouse, just a graphic tablet. The visitor can record and play or change effects (before recording) a video of his/her eyes by clicking on buttons displayed on the gem window downside the video rendering (the rectangle), at the same time the visitor's voice is recorded with writesf~. The two documents are renamed with creation's date and stored into respective folders for being played later with another part of the same application which is a kind of video mixer. So I need to store the video capture (with the effect) into the hard drive or somewhere for beeing mixed later with the video of other visitors, voilà. cyrille Patrice Colet a écrit : I would like rather something like this [gemhead] | [pix_video] | [pix_crop] | [rectangle 4 1.5] | [pix_write] to write in a file what I see into the rectangle only. it currently work with [pix_record] cyrille henry a écrit : hello, unless i misunderstand, what you describe is currently working. gemhead 99 | pix_write will capture in a file what you can see in the gem windows. cyrille Patrice Colet a écrit : Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. The only *multiplatform* solution I'm thinking about is rendering the framebuffer into tiff files, cropping and transforming them to a lighter file format with imagemagicks controlled by a script file loaded with [popen], for having my texture rendered into a decent quality, that's quite complicated. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? Many thanks if you have a simple answer or another solution. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] GridFlow 0.9.1
On 23/05/2008, at 15.51, marius schebella wrote: just wanted to say that it needed some time, but finally this also runs on mac (at least on intel with os x 10.5). thanks to mathieu! How did you go by installing? I'm confused since the install guide in the manual [0] mentions ruby but the changelog for 0.9.1 says ruby have been removed (so it can't be called rubyext anymore right?). [0] http://gridflow.ca/svn/trunk/doc/install.html ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] GridFlow 0.9.1
Steffen Juul wrote: On 23/05/2008, at 15.51, marius schebella wrote: just wanted to say that it needed some time, but finally this also runs on mac (at least on intel with os x 10.5). thanks to mathieu! How did you go by installing? I'm confused since the install guide in the manual [0] mentions ruby but the changelog for 0.9.1 says ruby have been removed (so it can't be called rubyext anymore right?). [0] http://gridflow.ca/svn/trunk/doc/install.html it's a long story, and is far away from being automatic.. but yes, all ruby was removed. grab the latest sources and then do ./configure --no-mpeg3. after that add the path to your pd sources to the CFLAGS in config.make. mine is -I/Users/marius/devel/pd-rsync/pd-extended/pd/src and set -mtune=k8 -march=k8 if you have an intel mac. then it should compile and run. have not tested all objects, some seem not to work (like live input?), but most of them will. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
On Sat, May 24, 2008 at 7:18 AM, Patrice Colet [EMAIL PROTECTED] wrote: Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). The contents of the framebuffer are exactly what you see onscreen. I don't understand what is 'poor' about the image being read back. We can render framebuffer into picture files with the help of [pix_write], but I don't know any simple solution yet to render directly into pict files what we can get with the 'unstable' [pix_record]. pix_record on OSX is extremely well tested. I've recorded in excess of one million files with it. So my question that will certainly stay unanswered is/ What about adding a simple option to [pix_write] for rendering into picture files only the texture created by a gemchain instead of the framebuffer? pix_write should just write the pix buffer to a file and not also have pix_snap functionality embedded in it. Unfortunately doing this would break a lot of patches. Maybe pix_image_write would be an acceptable option. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
chris clepper wrote: On Sat, May 24, 2008 at 7:18 AM, Patrice Colet [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, it's possible to render on a video file the texture drawn into a geo object, but the quality is always poor whatever codec we use (even uncompressed files), that can be useful for having poor animated textures, but anyway the quality is never as good as we can get when we render into picture files (isn't it?). The contents of the framebuffer are exactly what you see onscreen. I don't understand what is 'poor' about the image being read back. you are right, I only want to add two tiny comments: gemframebuffer does not allow changing of view and perspec and it has no FSAA like onscreen. marius. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
Patrice Colet a écrit : Patrice Colet a écrit : chris clepper a écrit : pix_write should just write the pix buffer to a file and not also have pix_snap functionality embedded in it. Unfortunately doing this would break a lot of patches. Maybe pix_image_write would be an acceptable option. Something like this would be marvellous! For the moment I'm studying Cyrille's solution on linux because on windows [gemframebuffer] doesn't seem to do what we are expecting... Expectedly, gemframebuffer works good under linux, and it would be the solution if pix_write had a fourth inlet that has pix_texture second inlet's functionnality, i guess it wouldn't break anything. Forget it I've been mistaken, this not really the solution... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] gem2pdp
ola, yes, i saw the latest svn version can _compile_ with latest gem cvs ( some sport involved there ), but pdp2gem and pix_2pdp do not work, i get black or no-output in both case. what i see from analyzing the code is that the function : glReadPixels(m_x, m_y, m_image-xsize, m_image-ysize, m_image-format, m_image-type, m_image-data); with : m_image-type = GL_UNSIGNED_BYTE; m_image-format = GL_RGBA; returns a black image ( all bytes are 0 ), so something has changed here? saludos, sevy ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [GEM] pix_write option for rendering a texture only
hello, Patrice Colet a écrit : chris clepper a écrit : pix_record on OSX is extremely well tested. I've recorded in excess of one million files with it. I don't know OSX but on windows ( I'm gonna try right now on linux after wgetting and dpkging latest pd-extended) pix_record crashes pd if the record path is wrong (that's quite a bug for me) and the video isn't always well rendered if pix_record replaces a video file (which is quite another bug dattebayo)... pix_record also crashes pd on linux if the record path is wrong or empty when gemwin rendering is turned on, and terminal spits a segmentation error... Anyway, I'll have to deal with pix_record, thank you for all the answers even if the problem is still unresolved. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UI developer volunteering to help
Since it's been a few days since my last update, and I haven't received any
responses, I submitted patch #1971585 to SourceForge, including the updates
to the Path and Startup dialogs. Any further suggestions are still welcome;
I will be investigating consolidation of the 4 preferences dialogs into a
tabbed dialog of some sort (a la Tk notebook). However, perhaps an earlier
priority for me will be figuring out some improvements to GUI control
dialogs; perhaps bulk-editing/updates modeled (I think) on the iTunes UI for
editing the metadata on multiple songs.
Anyways, thank you to everyone who offered feedback and code reviews to my
efforts! Much appreciated. I'm grateful to be able to contribute code to a
piece of software that has been so useful to me in the past.
Best,
David
On Wed, May 21, 2008 at 8:50 PM, David Golightly [EMAIL PROTECTED] wrote:
Ok, how does this look?
I was still unable to reproduce the clicking bug, but I changed the code to
avoid the scenario that your stack trace seems to indicate as the problem,
hopefully you won't see it any more.
Turns out I also have Tcl/Tk 8.4.7. Don't know where I got the idea I had
8.5 installed. So it seems either the tcllib or the Tile/ttk widgets might
be a good bet for the next revision to these dialogs. One goal here also I
think is to eventually provide a good basis for further customization of the
Pd environment and UI, which will of course require someone to delve in the
C for some of it, although perhaps to the extent that some customization can
be done in pure Tcl/Tk, C work can be avoided.
Thanks again,
David
On Tue, May 20, 2008 at 3:00 AM, Hans-Christoph Steiner [EMAIL PROTECTED]
wrote:
Just tried your new version, very nice, I think it's sorted, except one
tiny bug with the resizing of Add new startup command. I think you'll
want to set a minimum window width, since you can resize it smaller and make
the OK button disappear.
You might look into the Tile/ttk widgets, they are now included in Tcl/Tk
8.5. I'd like to use 8.5 for Pd-extended 0.41, so they would be there. For
example, a ttk::notebook could be used to host all of the pref panes into a
single window.
About the error, I just dropped your u_main.tk into Pd-vanilla 0.41-4, so
that uses the version of Tcl/Tk included with Mac OS X, 8.4.7. I have
Tcl/Tk 8.4.18 installed, it might be using that. But I definitely don't
have 8.5 Here's the error:
Startup panel:
can't use empty string as operand of +
can't use empty string as operand of +
while executing
expr {$height + $top}
(procedure ScrollBox::dbl_click line 8)
invoked from within
ScrollBox::dbl_click .gfxstub5b1230 dlg_Startup::edit dlg_Startup::add 65
45
(command bound to event)
Path pane:
can't use empty string as operand of +
can't use empty string as operand of +
while executing
expr {$height + $top}
(procedure ScrollBox::dbl_click line 8)
invoked from within
ScrollBox::dbl_click .gfxstub5b1930 dlg_Path::edit dlg_Path::add 81 42
(command bound to event)
.hc
On May 20, 2008, at 8:32 AM, David Golightly wrote:
PS I was unable to reproduce that issue where you saw an error message
from clicking on an empty cell. For me, clicking on empty cells just
brought up the Add new item dialog. Could this be a difference of
platform/TclTk version? I'm running 8.5 on OS X 10.4. I'd also like to get
the specific error message if you can get it.
Thanks,
David
On Mon, May 19, 2008 at 10:07 PM, David Golightly [EMAIL PROTECTED]
wrote:
Here's a revised copy with a few minor changes (the startup flags field
now expands to fill the window, you can resize the startup command popup
arbitrarily).
I'm wondering about the protocol of introducing dependencies in PD. It
seems that BWidget gives us a widget that we can use for the listbox (
http://tcllib.sourceforge.net/BWman/ListBox.html), however, it's perhaps
not distributed with older distributions of Tcl/Tk. BWidget is distributed
with Tcllib, which is apparently a default library packaged with most
installs of Tcl, http://wiki.tcl.tk/12099 says that it comes by default
with the ActiveState distro, with .deb and .rpm packages, and it was
installed by default on my Mac OS X 10.4 distribution. But it's not
guaranteed to be installed with ALL distributions of Tcl/Tk - I just have no
idea exactly how many users might lack it.
Failing that, the popup should behave exactly as inline editing does,
even though it looks a little strange. You can still use the keyboard to
navigate: down, down, enter, type, enter, up, enter, esc... Just think of
it as inline listbox editing with extra window chrome :)
On Mon, May 19, 2008 at 11:37 AM, Hans-Christoph Steiner [EMAIL PROTECTED]
wrote:
Oops, found a little bug: double-clicking on an empty cell through up
an error dialog.
Also, an idea: if you just draw that popup entry box just below the
listbox with the
