Some confusion about linux amd64-64 and linux amd64-32 in deken, and what are all the possible variations?
Hello list! I have some questions regarding the architectures available in deken
I noticed that deken has many different architectures possible for the packages, as i checked by now (not an exhaustive search) there is at least 8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32, armv7-64, armv7l-32), at least 4 for mac (amd64-32, x86_64-32, i386-32, PowerPC-32) and at least 2 for windows (amd64-32, i386-32).
There are more? And are they correct? Should i expect that all mac and windows may have the -64 variant too? I ask this because I want to create a table showing all the externals available and which downloads are possible from deken, together with descriptions for each external, so i want to know what are the possible architectures that I am missing... see the (unfinished) table here https://pdwiki.miraheze.org/wiki/List_of_Externals#List_of_Externals
So for the first question of the e-mail, what is the difference between amd64-64 and amd64-32? I guess that the first name would be for the architecture of the system, and then the last 32 or 64 would be for single or double precision... but if I search for bandlimited in deken for example, i get that its package is amd64-64 for linux, and i can install it on normal pd, but pd double refuses it, as it is a 32bit-float object. Well, bandlimited was uploaded in 2016, way before the pd double came to vanilla (maybe 2019?), so it makes sense that it is 32bit-float... But there were other reasons for it (and other externals, some from extended) to be packaged as linux amd64-64 instead of amd64-32?
if I'm not mistaken the appending 32 or 64 is for 32 or 64 bit Pd, that is, the application.
the first part is the cchp architecture.
I welcome and support your efforts, but I'll make the remark again that I hope you could bring much of what what you're planning to puredata.info for a more centralized online resource, and we can also add things to the manual. This section already describes the binary types, we can maybe improve it => http://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1
cheers
Em sex., 24 de dez. de 2021 às 15:25, José de Abreu abreubacelar@gmail.com escreveu:
Hello list! I have some questions regarding the architectures available in deken
I noticed that deken has many different architectures possible for the packages, as i checked by now (not an exhaustive search) there is at least 8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32, armv7-64, armv7l-32), at least 4 for mac (amd64-32, x86_64-32, i386-32, PowerPC-32) and at least 2 for windows (amd64-32, i386-32).
There are more? And are they correct? Should i expect that all mac and windows may have the -64 variant too? I ask this because I want to create a table showing all the externals available and which downloads are possible from deken, together with descriptions for each external, so i want to know what are the possible architectures that I am missing... see the (unfinished) table here https://pdwiki.miraheze.org/wiki/List_of_Externals#List_of_Externals
So for the first question of the e-mail, what is the difference between amd64-64 and amd64-32? I guess that the first name would be for the architecture of the system, and then the last 32 or 64 would be for single or double precision... but if I search for bandlimited in deken for example, i get that its package is amd64-64 for linux, and i can install it on normal pd, but pd double refuses it, as it is a 32bit-float object. Well, bandlimited was uploaded in 2016, way before the pd double came to vanilla (maybe 2019?), so it makes sense that it is 32bit-float... But there were other reasons for it (and other externals, some from extended) to be packaged as linux amd64-64 instead of amd64-32? _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
+1 for both efforts.
I am a little confused what to install on my mac, that i feel more clarity of the documentation in this matter is really welcome.
Merry christmess to all!
Alexandre Torres Porres porres@gmail.com schrieb am Sa., 25. Dez. 2021, 00:03:
Em sex., 24 de dez. de 2021 às 19:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
if I'm not mistaken
I'm definitely mistaken
btw, merry xmas everybody _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Well, but the good thing about deken is that you don't need to know about anything to get confused or not. Whatever runs on your system is highlighted and offered to you. So what is the 'confusion'?
I'm now shipping for all the 8 suppoorted platforms on the same download. Here's what we have for the latest versions of Cyclone and ELSE.
(Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv6-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32)
So yeah, it seems the '32' at the end is about single precision (let's talk about single and double precision to avoid confusion). I offer a "fat" binary for mac that runs on both Pd 32 bits and 64 bits (32 is 'i386' and 64 is 'amd64). Window is just like that but there are separate binaries for each. Linux is also like that with separate binaries but there are also 'arm' versions for linux for raspberry pies: armv6 is for pi zero I think and it's 32 bits.
the binaries are
.d_fat .l_amd64 .l_arm .l_arm64 .l_i386 .m_amd64 .m_i386
According to http://msp.ucsd.edu/Pd_documentation/x4.htm#s1.2.1 and what I know, I can add
(Darwin-amd64-32)(Darwin-i386-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv6-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32)
- (Darwin-amd64-32)(Darwin-i386-32) => .d_fat - multiple archs for macOS:
d_i386/intel 32 bits (for Pd 32 bits) & d_amd64/intel 64 bits (Pd 64 bits)
- (Linux-amd64-32) => .l_amd64 - Linux (Intel/AMD 64bit) for Pd 64 bits
- (Linux-armv6-32) => .l_arm - Linux arm (e.g. RaspberryPi) for Pd 32 bits
(?)
- (Linux-arm64-32) => .l_arm64 - Linux arm64 (also for rasp) for Pd 64 bits.
- (Linux-i386-32) => .l_i386 - Linux i386 (Intel/AMD 32bit) for Pdd 32 bits
- (Windows-amd64-32) => .m_amd64 - amd64 (Intel/AMD 64bit) for Windows 64
bits
- (Windows-i386-32) => .m_i386 - i386 (Intel/AMD 32bit) for windows 64 bits
Now, I see i ddeken ceammcv0.9.4 http://puredata.info/Members/anadjarov/software/ceammc/0.9.4/ceammc%5Bv0.9.4%5D%28Darwin-amd64-64%29.dek.sha256/view which I believe is foor Pd double precision.
Em sex., 24 de dez. de 2021 às 22:06, Johnny Mauser < joson.android@googlemail.com> escreveu:
+1 for both efforts.
I am a little confused what to install on my mac, that i feel more clarity of the documentation in this matter is really welcome.
Merry christmess to all!
Alexandre Torres Porres porres@gmail.com schrieb am Sa., 25. Dez. 2021, 00:03:
Em sex., 24 de dez. de 2021 às 19:46, Alexandre Torres Porres < porres@gmail.com> escreveu:
if I'm not mistaken
I'm definitely mistaken
btw, merry xmas everybody _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Greetings. A colleague told me that I shouldn't upgrade to the Big Sur MacOS because starting with that release (and in all subsequent ones) GEM and video in general stop working. Can anyone verify this? And if it's true, have the GEM developers posted anything about future functionality? Thank you! -Dana Moser Mass. College of Art and Design
Hi Dana and all,
I upgraded my personal computer to a new arm Mac and can confirm, that Gem is not running properly out of the box. I don’t know whether I made a mistake, or it is the general situation, or what’s going on..
MacOS 12.1 Pd 52.1, Gem 0.94
Trying to create a Gem window leads to console showing: "[gemmacoswindow]: failed to init GLEW: your system only supports openGL-1.0“
When I open the backendinfo window from the help-patch of pix_video the [AVF-videoplugin $0] object could not be created. AVF-videoplugin
Gem is loading and printing on startup:
GEM: Graphics Environment for Multimedia GEM: ver: 0.94.git v0.94 GEM: compiled on Feb 12 2019 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage https://gem.iem.at/ GEM: bug-tracker https://bugs.gem.iem.at/ GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for MMX/SSE2 architecture GEM: using SSE2 optimization GEM: detected 10 CPUs GEM: image loading plugins: magick SGI STB imageIO jpeg tiff GEM: film loading plugins: AVF quicktime4linux GEM: image saving plugins: SGI STB imageIO jpeg magick tiff GEM: model loading plugins: ASSIMP3 OBJ GEM: video record plugins: QT4L GEM: video capture plugins: AVF decklink
Any suggestions what to do?
Thx in advance,
Jonas
Am 25.12.2021 um 22:19 schrieb Dana Moser rosalux@curiousart.org:
Greetings. A colleague told me that I shouldn't upgrade to the Big Sur MacOS because starting with that release (and in all subsequent ones) GEM and video in general stop working. Can anyone verify this? And if it's true, have the GEM developers posted anything about future functionality? Thank you! -Dana Moser Mass. College of Art and Design
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/28/21 21:33, Johnny Mauser via Pd-list wrote:
Hi Dana and all,
I upgraded my personal computer to a new arm Mac and can confirm, that Gem is not running properly out of the box. I don’t know whether I made a mistake, or it is the general situation, or what’s going on..
MacOS 12.1 Pd 52.1, Gem 0.94
Trying to create a Gem window leads to console showing: "[gemmacoswindow]: failed to init GLEW: your system only supports openGL-1.0“
that's https://github.com/umlaeute/Gem/issues/257 et al.
the solution is to replace the [gemmacoswindow] within the gemdefaultwindow.pd abstraction (which is used within [gemwin]) with [gemglfw3window] (or [gemglutwindow]).
When I open the backendinfo window from the help-patch of pix_video the [AVF-videoplugin $0] object could not be created. AVF-videoplugin
that's a separate (minor) issue, that just indicates that there's a lack of documentation for the AVF backend of [pix_video]. it doesn't indicate any malfunctioninig of [pix_video] per se (it doesn't indicate the opposite either; it is just orthogonal)
gfdmsy IOhannes
Thanks IOhannes, worked!
So, Dana, I didn't test old patches yet, but I can confirm Gem working on MacOS 12.
Am 28.12.2021 um 23:07 schrieb IOhannes m zmölnig zmoelnig@iem.at:
On 12/28/21 21:33, Johnny Mauser via Pd-list wrote:
Hi Dana and all, I upgraded my personal computer to a new arm Mac and can confirm, that Gem is not running properly out of the box. I don’t know whether I made a mistake, or it is the general situation, or what’s going on.. MacOS 12.1 Pd 52.1, Gem 0.94 Trying to create a Gem window leads to console showing: "[gemmacoswindow]: failed to init GLEW: your system only supports openGL-1.0“
that's https://github.com/umlaeute/Gem/issues/257 et al.
the solution is to replace the [gemmacoswindow] within the gemdefaultwindow.pd abstraction (which is used within [gemwin]) with [gemglfw3window] (or [gemglutwindow]).
When I open the backendinfo window from the help-patch of pix_video the [AVF-videoplugin $0] object could not be created. AVF-videoplugin
that's a separate (minor) issue, that just indicates that there's a lack of documentation for the AVF backend of [pix_video]. it doesn't indicate any malfunctioninig of [pix_video] per se (it doesn't indicate the opposite either; it is just orthogonal)
gfdmsy IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi list,
experiencing some weird issues with Gem 0.94.git v0.94 on MacOS 12.4 as well. Upon trying to create a gemwindow I am getting [gemmacoswindow]: unable to switch to current window (do you have one?), cannot render! Seems to be https://github.com/umlaeute/Gem/issues/257 Following some advice to a different, but possibly related error, I replaced [gemmacoswindow] with [gemglfw3window]. This made the window appear and render.
What is the difference between [gemglfw3window] and [gemglutwindow]? In one of the two, the origin of the coordinate system seems to be off in fullscreen more and and contents are rendered smaller, possibly related to https://github.com/umlaeute/Gem/issues/261 in the other one, there is often flickering.
I tried to make Gem output on a second screen (extended desktop) next. When I use the [fullscreen 1] message, th OS will change the resolution of that second display to that of gemwin's "dimen" setting. But whenever I want to edit the patch and focus the patch window, the fullscreen gemwindow on the external display is minimized to the dock, and the resolution of that external display changed back by the OS setting it to as it was before. Makes it impossible to work. Without the fullscreen message, the title bar of the Gem window is always visible.
Can anyone perhaps test and confirm, possibly also explain, this last issue?
Thank you! Peter
- IOhannes m zmölnig zmoelnig@iem.at [2021-12-28 23:08]:
On 12/28/21 21:33, Johnny Mauser via Pd-list wrote:
Hi Dana and all,
I upgraded my personal computer to a new arm Mac and can confirm, that Gem is not running properly out of the box. I don’t know whether I made a mistake, or it is the general situation, or what’s going on..
MacOS 12.1 Pd 52.1, Gem 0.94
Trying to create a Gem window leads to console showing: "[gemmacoswindow]: failed to init GLEW: your system only supports openGL-1.0“
that's https://github.com/umlaeute/Gem/issues/257 et al.
the solution is to replace the [gemmacoswindow] within the gemdefaultwindow.pd abstraction (which is used within [gemwin]) with [gemglfw3window] (or [gemglutwindow]).
When I open the backendinfo window from the help-patch of pix_video the [AVF-videoplugin $0] object could not be created. AVF-videoplugin
that's a separate (minor) issue, that just indicates that there's a lack of documentation for the AVF backend of [pix_video]. it doesn't indicate any malfunctioninig of [pix_video] per se (it doesn't indicate the opposite either; it is just orthogonal)
gfdmsy IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Peter,
In April I wrote this but never got an answer:
since I moved to [gemglfw3window] as gemwin has not been created on since Big Sur I am unable to make borderless screen. Is there a workaround? [fullscreen 2( is not my option.
Best,
Popesz
On Fri, 10 Jun 2022 at 07:49, Peter P. peterparker@fastmail.com wrote:
Hi list,
experiencing some weird issues with Gem 0.94.git v0.94 on MacOS 12.4 as well. Upon trying to create a gemwindow I am getting [gemmacoswindow]: unable to switch to current window (do you have one?), cannot render! Seems to be https://github.com/umlaeute/Gem/issues/257 Following some advice to a different, but possibly related error, I replaced [gemmacoswindow] with [gemglfw3window]. This made the window appear and render.
What is the difference between [gemglfw3window] and [gemglutwindow]? In one of the two, the origin of the coordinate system seems to be off in fullscreen more and and contents are rendered smaller, possibly related to https://github.com/umlaeute/Gem/issues/261 in the other one, there is often flickering.
I tried to make Gem output on a second screen (extended desktop) next. When I use the [fullscreen 1] message, th OS will change the resolution of that second display to that of gemwin's "dimen" setting. But whenever I want to edit the patch and focus the patch window, the fullscreen gemwindow on the external display is minimized to the dock, and the resolution of that external display changed back by the OS setting it to as it was before. Makes it impossible to work. Without the fullscreen message, the title bar of the Gem window is always visible.
Can anyone perhaps test and confirm, possibly also explain, this last issue?
Thank you! Peter
- IOhannes m zmölnig zmoelnig@iem.at [2021-12-28 23:08]:
On 12/28/21 21:33, Johnny Mauser via Pd-list wrote:
Hi Dana and all,
I upgraded my personal computer to a new arm Mac and can confirm,
that Gem is not running properly out of the box. I don’t know whether I made a mistake, or it is the general situation, or what’s going on..
MacOS 12.1 Pd 52.1, Gem 0.94
Trying to create a Gem window leads to console showing:
"[gemmacoswindow]: failed to init GLEW: your system only supports openGL-1.0“
that's https://github.com/umlaeute/Gem/issues/257 et al.
the solution is to replace the [gemmacoswindow] within the gemdefaultwindow.pd abstraction (which is used within [gemwin]) with [gemglfw3window] (or [gemglutwindow]).
When I open the backendinfo window from the help-patch of pix_video
the [AVF-videoplugin $0] object could not be created.
AVF-videoplugin
that's a separate (minor) issue, that just indicates that there's a lack
of
documentation for the AVF backend of [pix_video]. it doesn't indicate any malfunctioninig of [pix_video] per se (it doesn't indicate the opposite either; it is just orthogonal)
gfdmsy 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
On 12/24/21 19:22, José de Abreu wrote:
Hello list! I have some questions regarding the architectures available in deken
I noticed that deken has many different architectures possible for the packages, as i checked by now (not an exhaustive search) there is at least 8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32, armv7-64, armv7l-32), at least 4 for mac (amd64-32, x86_64-32, i386-32, PowerPC-32) and at least 2 for windows (amd64-32, i386-32).
the format is documented at: https://github.com/pure-data/deken/tree/master/developer#filename-format
There are more?
theoretically many more. the specifier is open for new CPU-architectures, floatsizes and OSs.
example, i get that its package is amd64-64 for linux, and i can install it on normal pd, but pd double refuses it, as it is a 32bit-float object.
ah yes. we are currently at the deken format-specification "1", which mandates a .dek extension and which defines a strict interpretation of the architecture specifier. there's *also* the legacy deken format-specification "0" (the packages with .zip, .tgz or .tar.gz extensions), which was much more relaxed and thus created the confusion that you are now seeing. in this format, the last number was indeed not very clearly defined, and people used if for multiple things. the use of the deken v0 is highly discouraged (exactly because it is not well-defined) for new packages, but the packages can still be consumed (as the original Pd-extended batch upload used this format).
in practice, all packages that use deken v0 are single-precision float, and that last number is practically useless and is therefore ignored by both the deken-plugin (that is: when searching externals from within Pd) and the websearch on https://deken.puredata.info
from deken, together with descriptions for each external, so i want to know what are the possible architectures that I am missing... see the (unfinished) table here
that table is going to always be unfinished, *unless* you automatically generate it from https://deken.puredata.info (and possibly other sources). now you can query deken.puredata.info for available externals and it will give you the result in TSV, JSON or HTML. so if you want to take that route, go ahead. feedback on the API is welcome, e.g. at https://git.iem.at/zmoelnig/deken-server
but manually maintaining such a table seems a bit crazy (well: futile) too me.
gfmds IOhannes
On 12/26/21 13:20, IOhannes m zmölnig wrote:
different architectures possible for the packages, as i checked by now (not an exhaustive search) there is at least 8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32, armv7-64, armv7l-32)
indeed not very exhaustive. i wonder how you obtained this list.
i know at least of one package that claims to provide binaries for Linux/alpha/single precision, Linux/s390x both single and double precision, and Windows/x86 double precision.
mgfds IOhannes
Thanks for all inputs (and merry christmas to all), i will try to look at deken sources and see if i can do something to auto generate the table using some modified deken output, i may came in the next days with more questions
btw my list was all by "human parsing" the first 40 entries of deken in alphabetical order, lol (and i know there are way more than 100 packages in deken...) but indeed doing this by hand is bad... i will try to learn how to do this parsing http get request to deken server, and write the descriptions in separate
Em dom., 26 de dez. de 2021 às 09:28, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 12/26/21 13:20, IOhannes m zmölnig wrote:
different architectures possible for the packages, as i checked by now (not an exhaustive search) there is at
least
8 for linux, (amd64-32, amd64-64, i386-32, arm64-32, armv6-32, armv7-32, armv7-64, armv7l-32)
indeed not very exhaustive. i wonder how you obtained this list.
i know at least of one package that claims to provide binaries for Linux/alpha/single precision, Linux/s390x both single and double precision, and Windows/x86 double precision.
mgfds IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Csaba Láng -
Dana Moser -
IOhannes m zmölnig -
Johnny Mauser -
José de Abreu -
Peter P.