hi, list !
couldn't find anything in the archives that provided a solution, just discussions about it, so here i go again:
is it possible to have something like a preview window for Gem output (or even single pixes or textures) ?
or are there any workarounds ?
i read about a preview made of data structures, but never found a downloadable patch for it ...
thanks for any hints !
best
oliver
On 10/15/2017 08:10 PM, oliver wrote:
hi, list !
couldn't find anything in the archives that provided a solution, just discussions about it, so here i go again:
is it possible to have something like a preview window for Gem output (or even single pixes or textures) ?
or are there any workarounds ?
i read about a preview made of data structures, but never found a downloadable patch for it ...
thanks for any hints !
the simplest solution is to just create a large window that gets displayed both on your secondary "public" screen (in fullscreen) and on your primary "control" screen (only a small portion). then render everything into a framebuffer, and render *that* as a texture on both the public and the control screen.
also the current git theoretically supports multiple windows (though there might be a number of glitches).
gamdsr IOhannes
It is also possible to use [pix_share_read] and [pix_share_write] to share pix_ between two instances of Pd (with Gem). ++
Jack
Le 15/10/2017 à 20:15, IOhannes m zmölnig a écrit :
On 10/15/2017 08:10 PM, oliver wrote:
hi, list !
couldn't find anything in the archives that provided a solution, just discussions about it, so here i go again:
is it possible to have something like a preview window for Gem output (or even single pixes or textures) ?
or are there any workarounds ?
i read about a preview made of data structures, but never found a downloadable patch for it ...
thanks for any hints !
the simplest solution is to just create a large window that gets displayed both on your secondary "public" screen (in fullscreen) and on your primary "control" screen (only a small portion). then render everything into a framebuffer, and render *that* as a texture on both the public and the control screen.
also the current git theoretically supports multiple windows (though there might be a number of glitches).
gamdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
hi,
as IOhannes mentionned it, you can also use multiple rendering window. one for your main display and as many as you want for the preview. There are some examples under 'examples/14.multiple_windows' folder.
best
antoine
-- do it yourself http://antoine.villeret.free.fr
2017-10-15 20:29 GMT+02:00 Jack jack@rybn.org:
It is also possible to use [pix_share_read] and [pix_share_write] to share pix_ between two instances of Pd (with Gem). ++
Jack
Le 15/10/2017 à 20:15, IOhannes m zmölnig a écrit :
On 10/15/2017 08:10 PM, oliver wrote:
hi, list !
couldn't find anything in the archives that provided a solution, just discussions about it, so here i go again:
is it possible to have something like a preview window for Gem output (or even single pixes or textures) ?
or are there any workarounds ?
i read about a preview made of data structures, but never found a downloadable patch for it ...
thanks for any hints !
the simplest solution is to just create a large window that gets displayed both on your secondary "public" screen (in fullscreen) and on your primary "control" screen (only a small portion). then render everything into a framebuffer, and render *that* as a texture on both the public and the control screen.
also the current git theoretically supports multiple windows (though there might be a number of glitches).
gamdsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
thanks a lot for all your suggestions !
i think i'll go the IOhannes route, seems to be the most practicable
best
oliver
Jack wrote:
It is also possible to use [pix_share_read] and [pix_share_write] to share pix_ between two instances of Pd (with Gem). ++
Jack
Le 15/10/2017 à 20:15, IOhannes m zmölnig a écrit :
On 10/15/2017 08:10 PM, oliver wrote:
hi, list !
the simplest solution is to just create a large window that gets displayed both on your secondary "public" screen (in fullscreen) and on your primary "control" screen (only a small portion). then render everything into a framebuffer, and render *that* as a texture on both the public and the control screen.
Hello,
I've been trying to develop an interface with sys_gui where media files are launched by clicking on a preview image, like in almost all softwares managing media files.
It's done by dumping pixels from gemwin to a bitmap stored in datastructure that is designing the launching buttons of my tck-tk interface.
With Purr Data, there is no sys_gui but we don't need such a complex coding to reach this end by the use of [draw] object.
In this attached example the image preview has to be stored in the hard drive to be opened. It's a single image preview but it could be extended to animation view.
Le 16/10/2017 à 13:50, oliver a écrit :
thanks a lot for all your suggestions !
i think i'll go the IOhannes route, seems to be the most practicable
best
oliver
Jack wrote:
It is also possible to use [pix_share_read] and [pix_share_write] to share pix_ between two instances of Pd (with Gem). ++
Jack
Le 15/10/2017 à 20:15, IOhannes m zmölnig a écrit :
On 10/15/2017 08:10 PM, oliver wrote:
hi, list !
the simplest solution is to just create a large window that gets displayed both on your secondary "public" screen (in fullscreen) and on your primary "control" screen (only a small portion). then render everything into a framebuffer, and render *that* as a texture on both the public and the control screen.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Patrice Colet wrote:
Hello,
I've been trying to develop an interface with sys_gui where media files are launched by clicking on a preview image, like in almost all softwares managing media files.
It's done by dumping pixels from gemwin to a bitmap stored in datastructure that is designing the launching buttons of my tck-tk interface.
With Purr Data, there is no sys_gui but we don't need such a complex coding to reach this end by the use of [draw] object.
"draw sprite image 100 100 ... couldn't create"
is that a part of some external library ?
In this attached example the image preview has to be stored in the hard drive to be opened. It's a single image preview but it could be extended to animation view.
that will probably not be possible under windows 7/64bit (at least for me it wouldn't).
GEM freezes and dies when the number of files read by [pix_image] exceeds 2048. no workaround found yet. thread 0/1 doesn't change anything.
best
oliver
I remember this data-structure thing, but also cannot find it in my computer yet. On osx i sometimes use syphon as a workarround. Also i could imagine that there would be a solution with share-mem lib and a second instance..
Am 15.10.2017 8:10 nachm. schrieb "oliver" oliver@klingt.org:
hi, list !
couldn't find anything in the archives that provided a solution, just discussions about it, so here i go again:
is it possible to have something like a preview window for Gem output (or even single pixes or textures) ?
or are there any workarounds ?
i read about a preview made of data structures, but never found a downloadable patch for it ...
thanks for any hints !
best
oliver
-- \\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\ http://oliver.klingt.org \\\\\\\ ////////////////////////////////////////////////////////
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
-
Antoine Villeret -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jack -
Johnny Mauser -
oliver -
Patrice Colet