Am 26.03.2020 um 10:02 schrieb gem-dev-request@lists.iem.at:
Send GEM-dev mailing list submissions to
gem-dev@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.puredata.info/listinfo/gem-dev
or, via email, send a message with subject or body 'help' to
gem-dev-request@lists.iem.at
You can reach the person managing the list at
gem-dev-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of GEM-dev digest..."
Today's Topics:
1. Re: GEM-dev Digest, Vol 141, Issue 1 (Michael Beil)
2. GEM, OpenGL Depreciation and Metal on OSX (me.grimm)
3. Re: Someone sent a bogus pointer to copy2Image (was Re:
GEM-dev Digest, Vol 141, Issue 1) (IOhannes m zmölnig)
----------------------------------------------------------------------
Message: 1
Date: Wed, 25 Mar 2020 12:41:56 +0100
From: Michael Beil <post@michaelbeil.de>
To: gem-dev@lists.iem.at
Subject: Re: [GEM-dev] GEM-dev Digest, Vol 141, Issue 1
Message-ID: <E7073953-C7A9-40F2-B73C-AE773EF11CF5@michaelbeil.de>
Content-Type: text/plain; charset="utf-8"
after more testing yesterday I can describe more precisely:
I send an image from pix_video to a rectangle and I use a gemwin with the same resolution.
pix_video = 1280*720
gemwin = 1280*720
I use facetime (builtin), external webcam (logitech) and blackmagic intensity interface (USB3/HDMI)
I get a proper image and I can switch the cams. THAT’S GREAT !!!! :)
but
- when I change the resolution of pix_video I have to recreate gemwin to see the effect
- when I send create, 1 to gemwin I get the bogus errors and I have to wait for them popping up (more for facetime, less for external cams)
- real issue: the border 0 message to gemwin creates a black gap where the border was and changes the image frame (part of the image at the left side vanishes by an x-zoom, the window-size remains the same)
- the rectangle object needs weird numbers like 7.5 and 4 to get the image fitting to a gemwin, the original image is very small in the gemwin without scaling and adapting
I found the help-file for pix_video in the Max folder. But when I open it in the patch it is blank.
best
Michael
Am 25.03.2020 um 12:00 schrieb gem-dev-request@lists.iem.at:
Send GEM-dev mailing list submissions to
gem-dev@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.puredata.info/listinfo/gem-dev
or, via email, send a message with subject or body 'help' to
gem-dev-request@lists.iem.at
You can reach the person managing the list at
gem-dev-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of GEM-dev digest..."
Today's Topics:
1. GEM/Mac: Someone sent a bogus pointer to copy2Image (Michael Beil)
2. Re: GEM/Mac: Someone sent a bogus pointer to copy2Image
(IOhannes m zmölnig)
----------------------------------------------------------------------
Message: 1
Date: Tue, 24 Mar 2020 14:22:41 +0100
From: Michael Beil <post@michaelbeil.de>
To: gem-dev@lists.iem.at
Subject: [GEM-dev] GEM/Mac: Someone sent a bogus pointer to copy2Image
Message-ID: <343AD94E-91B3-4693-87E3-A6E1F0B65872@michaelbeil.de>
Content-Type: text/plain; charset=utf-8
Hi list,
I try to use a patch that worked with 0.43.4 with 0.5/Gem0.94 on a Mac.
There are a some strange things I could not figure out yet. At first, each time I create a gem-window I get a dozen of
GEM: Someone sent a bogus pointer to copy2Image
errors.
Even when I just use the help-patch for pix_video (e.g.) I get them. All other problems are maybe also related to pix_video. Especially wrong resolutions and image-distortion. So my second question is: Has pix_video been replaced? Or discontinued? Is the pix_video-help still „valid“?
Maybe this has been discussed already, sorry then :)
Thanks and best
Michael
------------------------------
Message: 2
Date: Tue, 24 Mar 2020 17:01:36 +0100
From: IOhannes m zmölnig <zmoelnig@iem.at>
To: gem-dev@lists.iem.at
Subject: Re: [GEM-dev] GEM/Mac: Someone sent a bogus pointer to
copy2Image
Message-ID: <6978e076-d568-7c68-6c22-1934301dc8b9@iem.at>
Content-Type: text/plain; charset="utf-8"
On 3/24/20 2:22 PM, Michael Beil wrote:
Even when I just use the help-patch for pix_video (e.g.) I get them. All other problems are maybe also related to pix_video. Especially wrong resolutions and image-distortion. So my second question is: Has pix_video been replaced? Or discontinued? Is the pix_video-help still „valid“?
just a quick reply: [pix_video] is fine (well: should be :-))
the help-patch is also still valid.
what do you mean with "wrong resolutions" and "image distortion"?
which camera are you using?
gfmards
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20200324/a23c4902/attachment-0001.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
GEM-dev mailing list
GEM-dev@lists.iem.at
https://lists.puredata.info/listinfo/gem-dev
------------------------------
End of GEM-dev Digest, Vol 141, Issue 1
***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20200325/8f14dff3/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 25 Mar 2020 12:47:06 -0400
From: "me.grimm" <megrimm@gmail.com>
To: gem-dev <gem-dev@iem.at>
Subject: [GEM-dev] GEM, OpenGL Depreciation and Metal on OSX
Message-ID:
<CACE5Q16LrFzDcuKJbjjRGJHW3J8kiUABm9D1SEc2mPmnYXdy3w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Getting lots of OpenGL depreciation warnings compiling GEM. macOS is
moving to its own Metal framework. I assume GEM will fail to run on macOS
at some point.
What does this mean for GEM on macOS? Is GEM 'dead' on macs? Can it be
transitioned with something like this: https://moltengl.com/ ? Do large
parts need to be re-written? Is there any hope?
I would say for macOS users to just go use Ofelia. Unfortunately, the
Ofelia learning curve seems very steep. For studio arts students that have
never programed before, never knew they had interest in programing, and are
learning the basics of creating interactive art, GEM offers very simple
objects and a consistent visual programing workflow that allows them to
transition from simple Pd Vanilla objects to GEM very easily. For them,
patience is not always a strong suit so getting something working quickly
sustains their interests much longer. Some of them even begin to use Pd/GEM
combo in their daily practice.
This said, it would be a shame if 'GEM is dead' on macOS. But maybe this is
an over reaction and the GEM future is bright.
m
--
____________________
m.e.grimm, m.f.a, ed.m.
cornell u., tc3
megrimm.net
____________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20200325/df767094/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 26 Mar 2020 10:02:08 +0100
From: IOhannes m zmölnig <zmoelnig@iem.at>
To: gem-dev@lists.iem.at
Subject: Re: [GEM-dev] Someone sent a bogus pointer to copy2Image (was
Re: GEM-dev Digest, Vol 141, Issue 1)
Message-ID: <2aa28762-b565-6012-c45d-11ee6db56b4e@iem.at>
Content-Type: text/plain; charset="utf-8"
On 3/25/20 12:41 PM, Michael Beil wrote:
after more testing yesterday I can describe more precisely:
I send an image from pix_video to a rectangle and I use a gemwin with the same resolution.
pix_video = 1280*720
gemwin = 1280*720
I use facetime (builtin), external webcam (logitech) and blackmagic intensity interface (USB3/HDMI)
I get a proper image and I can switch the cams. THAT’S GREAT !!!! :)
but
- when I change the resolution of pix_video I have to recreate gemwin to see the effect
oops. that should not be necessary.
- when I send create, 1 to gemwin I get the bogus errors and I have to wait for them popping up (more for facetime, less for external cams)
only when re-creating the gemwin, or also when creating it for the first
time?
do those errors stop eventually?
(might be, that the camera takes some time to start streaming images;
and Gem complains that it doesn't get any images).
I get them always,
sounds logic and explains the different amount of errors. besides there seems to be no effect.
it is a dozen with facetime and around 5 with logitech
is it avoidable?
- real issue: the border 0 message to gemwin creates a black gap where the border was and changes the image frame (part of the image at the left side vanishes by an x-zoom, the window-size remains the same)
not sure i understand what you are saying.
could you post a screenshot?
also, does the problem persist if you send the [border 0( *before* you
create the Gem-windows (for the first time)? or are you doing that anyhow.
please see attached screenshots
with border 0 message you get
- black space in the top
- different zoom/image detail on both sides and bottom
- different position of gemwin and of image on screen
also when I send border 0 before creating for the first time after opening.
https://www.dropbox.com/sh/e9es42dbai8hn1z/AABg-dCnAJxWQrSD8_rzjpuqa?dl=0
- the rectangle object needs weird numbers like 7.5 and 4 to get the image fitting to a gemwin, the original image is very small in the gemwin without scaling and adapting
this is expected behaviour.
a [rectangle] is not some space on the screen to be occupied by whatever
incoming video you have; but instead it is a representation of a
3d-dimensional object (without depth :-)) in a 3d-world, and you just
happen to look at it. the closer you (or the camera) is to the object,
the larger it gets. it's the same as with your TV, really :-)
in the default camera position, the upper window border is Y=+4 and the
lower window border is Y=-4; since [square] (and [rectangle]) really
expand from -size to +size, a [square] of size=4 will cover the entire
height of the screen.
depending on the aspect ration of your video (or your gemwindow/screen,
if you want to show the video fullscreen, even if you are distorting
it), you have to adjust the width of your [rectangle].
if the aspect ratio is 1:1, then an object that covers X=-4 thru X=+4
will cover the entire width of the window (as in [square 4]).
if the aspect ratio is 2:1, then you need a [rectangle 8 4].
if your aspect ratio is 1280/720 (which, after doing some maths is the
same as 1.777777/1 or (if we multiply by 4) 7.1111111/4), then you need
to use a [rectangle 7.111111111 4].
you can automate this with
|
[pix_info]
| | | |||
| [/]
| |
| [* 4]
| |
[rectangle 0 4]
actually it is a patch created by you many years ago and a found this pix_info trick in your patch. And I had to remove it unfortunately.
I also thought that I would need 7.111 to 4, but a 1280*720 image does not fit to the gemwin like this.
I had to try manually to get 5.5 to 3 which is not 16:9 or 1.7777 to 1. I need 1.83333 as ratio to make it fit.
Of course once I know it is no problem. But I would like to position many little crops of recorded video on the gemwin and for each position I have to try quite strange numbers and scaling factors. Maybe I should always use a scale-factor of 4? You used scale 3 in the patch very often.
AND: If pix_video and gemwin have the same size, here 1280/720, it works with 1.8333 to 1 with scale 3.
But when I make the gemwin smaller I get black gaps on both sides.
I found the help-file for pix_video in the Max folder. But when I open it in the patch it is blank.
Max-folder?
do you get some Tcl/Tk error in the Pd-console?
(Tcl) INVALID COMMAND NAME: invalid command name ".x16603aba0.c"
while executing
".x16603aba0.c delete 101a2d200BASE0"
("uplevel" body line 12)
invoked from within
"uplevel #0 $docmds“
doing again I get:
sigmund~
... couldn't create
bonk~
... couldn't create
choice
... couldn't create
hilbert~
... couldn't create
complex-mod~
... couldn't create
loop~
... couldn't create
lrshift~
... couldn't create
pd~
... couldn't create
rev1~
... couldn't create
rev2~
... couldn't create
rev3~
... couldn't create
stdout
... couldn't create
bob~
... couldn't create
best and thanks
Michael
gfmdsar
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20200326/9c601a4e/attachment.sig>
———————————————Hello and thanks for your answer,
Subject: Digest Footer
_______________________________________________
GEM-dev mailing list
GEM-dev@lists.iem.at
https://lists.puredata.info/listinfo/gem-dev
------------------------------
End of GEM-dev Digest, Vol 141, Issue 2
***************************************