Bugs item #3284037, was opened at 2011-04-11 07:19
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_blobtracker has dependencies not satisfied in Pd Extendd
Initial Comment:
The abstraction pix_blobtracker contains objects from iemmatrix, e.g. mtx_resize, but they are created as [mtx_resize] instead of [iemmatrix/mtx_resize]. The folder iemmatrix is not libdir'ed by default in Pd Extended (I don't know if it should), so those objects won't create and the abstraction is rendered useless unless you manually libdir iemmatrix.
Also note that the abstraction itself is not available as [pix_blobtracker], you have to write [Gem/pix_blobtracker], because Gem's directory is not added either, but I think it's fixed in the svn (read something about it in the pd-list or gem-dev)
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2011-04-27 15:20
Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-04-13 15:23
Message:
oh, I guess I can't attach a file because its Pending?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-04-13 15:22
Message:
Adding [declare -lib iemmatrix] and changing [mtx_*] to [mtx_mul] will work
on all permutations, I just tested it. I attached the patch.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-04-13 15:01
Message:
thanks for your report.
well, several things:
- [pix_blobtracker] depends on an 3rd party Pd-library, iemmatrix, where
the actual persistent labeling is implemented.
i thought about, whether it is a good idea to depend on 3rd party
libraries for objects, but in the end i thought that it is better to do
that than to duplicate code in Gem for such special purposes
- [pix_blobtracker] depends on iemmatrix as it is intended and distributed
by upstream.
if you cannot create [mtx_*] then you installation of iemmatrix is broken.
this is a Pd-extended bug
- it might be that pix_blobtracker] lacks an [import -lib iemmatrix] line
(i'll check that)
- for [mtx_*] you might have to load the "hexloader".
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-11 19:24
Message:
I'm changing the subject.
Maybe this is more a bug of Pd Extended as a "distribution" than of Gem.
pix_blobtrack simply depends on both Gem and iemmatrix.
The issue in Pd Extended is that it includes things that depend on other
things which are not included or are included in a way that does not work
properly (i.e. iemmatrix)
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-11 07:22
Message:
there is also a mtx_* object that also doesn't create but apparently is not
part of iemmatrix (replacing it with [iemmatrix/mtx_x] doen't fix it) and I
don't know which library it belongs to.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3284037&group_…
Bugs item #3292406, was opened at 2011-04-24 10:56
Message generated for change (Comment added) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-26 12:20
Message:
sorry, i did not see the DOCUMENTATION flag,
apologies for my last comment.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-26 11:49
Message:
@nusmuk,: by reporting a bug in the DOCUMENTATION category, I think I only
implied that something's wrong with the documentation, not necessarily that
something doesn't work. If I misunderstood the correct use of the
documentation category and documentation issues are not supposed to be
reported in this bugtracker then I apologise
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-04-26 10:28
Message:
thanks for the report;
i changed the help-patch to be very similar to the [pix_snap2tex] patch,
which mentions, that you need something drawn to the framebuffer in order
to be happy.
this also makes for a more interactive experience :-)
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 13:34
Message:
When reporting a bug, you did imply that things doesn't work.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-24 13:25
Message:
That's what I meant, that the help patch misses a lot of information. I
didn't mean to imply that pix_snap doesn't work as it should.
I am not very good with documentation prose so I don't think I can provide
an improved help patch; however I guess the scheme in the attached
snap_bare_minimum.pd could be a starting point
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 12:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3292406, was opened at 2011-04-24 12:56
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
>Status: Pending
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-26 13:49
Message:
@nusmuk,: by reporting a bug in the DOCUMENTATION category, I think I only
implied that something's wrong with the documentation, not necessarily that
something doesn't work. If I misunderstood the correct use of the
documentation category and documentation issues are not supposed to be
reported in this bugtracker then I apologise
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-04-26 12:28
Message:
thanks for the report;
i changed the help-patch to be very similar to the [pix_snap2tex] patch,
which mentions, that you need something drawn to the framebuffer in order
to be happy.
this also makes for a more interactive experience :-)
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 15:34
Message:
When reporting a bug, you did imply that things doesn't work.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-24 15:25
Message:
That's what I meant, that the help patch misses a lot of information. I
didn't mean to imply that pix_snap doesn't work as it should.
I am not very good with documentation prose so I don't think I can provide
an improved help patch; however I guess the scheme in the attached
snap_bare_minimum.pd could be a starting point
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 14:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3292406, was opened at 2011-04-24 12:56
Message generated for change (Settings changed) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-26 13:49
Message:
@nusmuk,: by reporting a bug in the DOCUMENTATION category, I think I only
implied that something's wrong with the documentation, not necessarily that
something doesn't work. If I misunderstood the correct use of the
documentation category and documentation issues are not supposed to be
reported in this bugtracker then I apologise
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-04-26 12:28
Message:
thanks for the report;
i changed the help-patch to be very similar to the [pix_snap2tex] patch,
which mentions, that you need something drawn to the framebuffer in order
to be happy.
this also makes for a more interactive experience :-)
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 15:34
Message:
When reporting a bug, you did imply that things doesn't work.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-24 15:25
Message:
That's what I meant, that the help patch misses a lot of information. I
didn't mean to imply that pix_snap doesn't work as it should.
I am not very good with documentation prose so I don't think I can provide
an improved help patch; however I guess the scheme in the attached
snap_bare_minimum.pd could be a starting point
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 14:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3292406, was opened at 2011-04-24 12:56
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
>Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-24 15:25
Message:
That's what I meant, that the help patch misses a lot of information. I
didn't mean to imply that pix_snap doesn't work as it should.
I am not very good with documentation prose so I don't think I can provide
an improved help patch; however I guess the scheme in the attached
snap_bare_minimum.pd could be a starting point
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 14:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3292406, was opened at 2011-04-24 10:56
Message generated for change (Comment added) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 12:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3177361, was opened at 2011-02-10 15:02
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: no images with FW camera
Initial Comment:
hello,
with Gem svn, ubuntu 10.04 (kernell 2.6.32), and a guppy pro (from AVT) connected with FW800, i can't have images.
(same result with a stingray from AVT)
the camera create a device /dev/raw1394 and /dev/video1394/0
i've got video plugin dv4l and dc1394.
coriender can grab images without any problem.
i don't know if it's related, but when creating pix_video object, i've got an error in the terminal :
libdc1394 error: Error: Failed to allocate iso bandwidth
libdc1394 error: Error: Failed to setup DMA capture
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-04-26 12:31
Message:
i added some "properties" to dc1394, which should allow you to set the
operation mode and the iso-speed from within the patch.
since i cannot find a dc1394 camera, please test whether this fixesyour
problem.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-02-11 12:25
Message:
ok, i find the solution.
adding :
dc1394_video_set_operation_mode(m_dccamera,DC1394_OPERATION_MODE_1394B);
before setting speed to 800 solve the problem.
so i've go an image. i don't know to make this to work with both FW400 and
FW800 device...
i still have a small problem : the device is not properly closed. after
quitting pd, i have to unpluged it if i want to use it again. (the green
led is blinking after closing pd, just like when grabbing is on).
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-02-11 11:56
Message:
if i change line 269 of file videoDC1394.cpp
from
dc1394speed_t speed=DC1394_ISO_SPEED_400;
to
dc1394speed_t speed=DC1394_ISO_SPEED_800;
iv've got more information about why this speed can't be allocated in the
terminal :
libdc1394 error: An ISO speed >400Mbps was requested while the camera is
in LEGACY mode. Please set the operation mode to OPERATION_MODE_1394B
before asking for 1394b ISO speeds
libdc1394 error: Error: Failed to allocate iso bandwidth
libdc1394 error: Error: Failed to setup DMA capture
i just don't know how to do that. any help is apreciated in order to make
this work for this camera.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-02-10 16:08
Message:
well, i did not have other cam connected when i tried this, so pix_video
tried all backend at the initialization.
so, i now have a v4l device on the computer.
when creating pix_video : no messages regarding 1394.
(only a message that say pix_video open a v4l2 device).
sending driver dc1394 gives in the terminal :
libdc1394 error: Error: Failed to allocate iso bandwidth
libdc1394 error: Error: Failed to setup DMA capture
and in pd log :
error videoDC1394: Generic failure: failed to enumerate
then, sending device /dev/raw1394 did not change anything.
if i do the other order :
recreate pix_video, sending device /dev/raw1394, i've got an error that
say V4L can not open this device.
then sending driver dc1394 print nothing.
the camera is in FW800, the computer have only a FW800 port...
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-02-10 15:15
Message:
this happens as soon as you create the [pix_video] object?
Gem tries to set the bandwidth to 400 when it _open_s the device, but
should fall back to whatever the device gives, if FW400 is not supported.
but if the problem already occurs when creating [pix_video] (that is: when
initializing the dc1394 infrastructure), it will never reach that...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3177361&group_…
Bugs item #3292406, was opened at 2011-04-24 12:56
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-04-26 12:28
Message:
thanks for the report;
i changed the help-patch to be very similar to the [pix_snap2tex] patch,
which mentions, that you need something drawn to the framebuffer in order
to be happy.
this also makes for a more interactive experience :-)
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 15:34
Message:
When reporting a bug, you did imply that things doesn't work.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-24 15:25
Message:
That's what I meant, that the help patch misses a lot of information. I
didn't mean to imply that pix_snap doesn't work as it should.
I am not very good with documentation prose so I don't think I can provide
an improved help patch; however I guess the scheme in the attached
snap_bare_minimum.pd could be a starting point
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-24 14:13
Message:
if you look at example 07.texture/07.feedback, you'll notice that pix_snap
work if you use [t b a] (and not only [t a b])...
if you send color 1 0 0 to the gemwin of your "test_snap.pd", you'll
notice that pix_snap does snap a red bufffer : it's because it's working.
but when you send a snap message when Gem did not draw an image, the buffer
is empty...
That is certainly why the help patch says that pix_snap work best in
single buffer mode (the buffer is not automatically clear).
So, i think pix_snap is working perfectly, but the help patch is clearly
missing lot's of information.
please, fell free to make a nice help patch that could replace the current
one.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3292406, was opened at 2011-04-24 12:56
Message generated for change (Tracker Item Submitted) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: documentation
Group: any operating system
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_snap help patch
Initial Comment:
According to pix_snap's help patch, one would expect that all you need to have pix_snap take a snapshot is to send it a "snap" message at an arbitrary moment, but that won't work.
The only way it works, is to send it the snap message just before the gemlist (0 ligical time before), i.e. with a [t a b]. This should definitely be mentioned in the help patch.
The current help patch gives no clue that the attached example test_snap.pd won't work and that in order to make it work you need to do like shown in attached test_snap_2.pd
The attached file snap_bare_minimum.pd shows the bare minimum (i think) which is needed to succesfully take a snapshot and I think something like this should be shown in the help patch.
By the way it would also be worth mentioning that a bang works as a synonim of "snap", though many will guess that.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3292406&group_…
Bugs item #3281206, was opened at 2011-04-08 23:07
Message generated for change (Comment added) made by sistisette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: rendering (e.g. display)
Group: any operating system
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: thin white primitive borders are shown despite texture
Initial Comment:
Sometimes, depending on their size and/or position, rectangles (and I guess other polygons too but I mainly work with rectangles) are shown with a thin white border even if they are textured with a pix that has no white pixel in the proximity of the border, e.g. a completely black image or an image whose pixels close to the border are all black or transparent.
This has been there for years, I've always seen this happen since I use gem, across many versions. This happens both with Linux and Windows, i don't know on Mac OS.
If a rectangle is moving or changing size, the borders appear and disappear. Most of the time they are absent, I mean the values of position and size that cause the borders to appear are just a small fraction of the total.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-23 17:39
Message:
Does the hardware really interpolate textures the wrong way? Are we sure
Gem is asking the hardware the right thing? If "repeat" is the fix, i
suspect it may mask the issue (i.e. make it less evident in some but not
all situations) rather than fix it, but I haven't tried it actually.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-04-09 00:35
Message:
This is not a gem problem. it's the way the hardware interpolate a texture.
i don't remember the exact configuration, but changing the default value
of "quality" and/or "repeat" of pix_texture change can fix this problem.
since it's not gem fault, and gem offer a solution, i think this can be
closed.
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-08 23:10
Message:
I hope it is ok to rise the priority. Though this is an old bug, it is a
real showstopper in a range of situations.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3281206&group_…