[GEM-dev] GEM-dev Digest, Vol 141, Issue 2
Michael Beil
post at michaelbeil.de
Sat Mar 28 16:40:43 CET 2020
> Am 26.03.2020 um 10:02 schrieb gem-dev-request at lists.iem.at:
>
> Send GEM-dev mailing list submissions to
> gem-dev at 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 at lists.iem.at
>
> You can reach the person managing the list at
> gem-dev-owner at 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 at michaelbeil.de>
> To: gem-dev at lists.iem.at
> Subject: Re: [GEM-dev] GEM-dev Digest, Vol 141, Issue 1
> Message-ID: <E7073953-C7A9-40F2-B73C-AE773EF11CF5 at 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 at lists.iem.at:
>>
>> Send GEM-dev mailing list submissions to
>> gem-dev at 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 at lists.iem.at
>>
>> You can reach the person managing the list at
>> gem-dev-owner at 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 at michaelbeil.de>
>> To: gem-dev at lists.iem.at
>> Subject: [GEM-dev] GEM/Mac: Someone sent a bogus pointer to copy2Image
>> Message-ID: <343AD94E-91B3-4693-87E3-A6E1F0B65872 at 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 at iem.at>
>> To: gem-dev at lists.iem.at
>> Subject: Re: [GEM-dev] GEM/Mac: Someone sent a bogus pointer to
>> copy2Image
>> Message-ID: <6978e076-d568-7c68-6c22-1934301dc8b9 at 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 at 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 at gmail.com>
> To: gem-dev <gem-dev at iem.at>
> Subject: [GEM-dev] GEM, OpenGL Depreciation and Metal on OSX
> Message-ID:
> <CACE5Q16LrFzDcuKJbjjRGJHW3J8kiUABm9D1SEc2mPmnYXdy3w at 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 at iem.at>
> To: gem-dev at 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 at 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.
(screenshot was to big, post rejected, see them here:)
https://www.dropbox.com/sh/e9es42dbai8hn1z/AABg-dCnAJxWQrSD8_rzjpuqa?dl=0 <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 at lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev
>
>
> ------------------------------
>
> End of GEM-dev Digest, Vol 141, Issue 2
> ***************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20200328/0393de88/attachment-0001.html>
More information about the GEM-dev
mailing list