Whatever works, really. In my experience, I find it useful to always try to simplify things. The less details there are, the less likely one of them will come back to haunt you.
A default build would not have the @loader_path, there is something in the Gem build system that is doing that. It makes sense for most plugins to do that. I thought it might be easy to have a separate setting for the gem_videoVLC.so since the plugins seem to have somewhat separate build systems.
Including the libvlc into Gem could mean version incompatibilities with Gem's libvlc and the installed VLC.app. On the other hand, always using VLC.app's libvlc could leave to version incompatibilities between Gem and VLC.app's libvlc.
I don't know the answer to this question, I think the key is to find out which will have the most stable interface and use that one. Is it the interface between libvlc and VLC.app? Then then include libvlc in Gem. Is int libvlc's API? then use the libvlc in VLC.app.
.hc
On Apr 5, 2012, at 10:15 AM, m.e.grimm wrote:
i guess we have to fix that colorspace thing on OSX once and for all...
yeah that would be nice. the colorspace for each of the plugins to get a normal image seem to all be different too. i cant locate the colorspace for videoVLC at the moment because it would be too time consuming for me to have to run:
install_name_tool -change @loader_path/lib/libvlc.5.dylib /Applications/VLC.app/Contents/MacOS/lib/libvlc.5.dylib gem_videoVLC.so
after each time i compile if im just making adjustments to colors on trial and error basis ... which is basicly what i did on imageMAGICK and filmMERLIN.
as hans said though: "useless without VLC itself. I see no need to include libvlc in Gem if videoVLC can use the libvlc included in the VLC.app."
and i wonder why NOT just include libvlc in Gem? hans suggestion seems to make total sense. but at the same time just including libvlc doesnt seem to be a big deal (or is it?) and then there would be no need to make a special modification to Gem to accommodate videoVLC looking to /Applications/VLC.app/Contents/MacOS/lib/libvlc.5.dylib instead of @loader_path/lib/libvlc.5.dylib...
i guess whatever is easier? or whatever is cleaner? now that im thinking about it adding libvlc to gem seems to be the cleaner solution but maybe im wrong... IDK.
On Thu, Apr 5, 2012 at 3:37 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-04-05 04:21, m.e.grimm wrote:
try [device screen://(
i used [device qtcapture://( which works. just the image is terribly blue-ish (see attached screen grab)
i guess we have to fix that colorspace thing on OSX once and for all...
and there is a delay....
i think we cannot do much about _that_. i found the delay to make live video input quite unusable on w32 (that is: if you want to do something reactive). i think this is less a problem of Gem than a problem of VLC itself (at least: i get a terrible delay when opening a video-device in the VLC application as well, e.g. on w32)
gmasr IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk99S8EACgkQkX2Xpv6ydvR1EQCgoFau4C6+dTxa/SCvbQTRyA5R MXQAn3F4NHhvEKGf5VAvjKItC2QWEXF6 =Z1Lu -----END PGP SIGNATURE-----
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-- ____________________ m.e.grimm | m.f.a | ed.m. megrimm@gmail.com _________________________________
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
----------------------------------------------------------------------------
“We must become the change we want to see. - Mahatma Gandhi