Does this forum not send email notifications when a topic you create gets replies? I didn't get any.

Anyway...

My patch used Vanilla plus GEM and a few externals. I got all the updated versions of all the externals and Gem.
Gem is the one that's causing most of the trouble... or rather all of the trouble.

I get GL stack underflows, crashes when closing the gemwin, "someone sent a bogus pointer..." and other errors, none of which existed back when I created the patch. I have started reporting the bugs to Gem, but it's hard to isolate them, narrow them down and create minimal reproducing examples, as the patch is very, very complex, and the last time I touched it (and Pd) 12 years ago it was running seamlessly and very stable. I also tested on Windows and it's even worse: there it crashes when opening the gemwin.

My goal is not to use the old version of Pd and Gem to run the patch. That would be my very, very last resort. One one hand I suspected a bc-breaking change in how Pd handled some kinds of messages and wanted to test that, but I have already discarded that; on the other hand I wanted to see if I could run the patch without issues on the old versions, and from there either (a) start trying to narrow down the issues, always comparing between the two versions (because I don't remember how half of the stuff works, so if I reduce it to a minimal patch and still get issues, I'm never sure whether I'm introducing errors in the patch) or maybe (b) offer the Gem developers my whole patch (I cannot publish it but I would trust them) as a black box that certainly triggers a bunch of bugs even though it's very far from a minimal test case. I can still do that but it would be nice to confirm that the patch runs with no errors with the older version on a modern machine and OS.

In the end I was able to compile Pd 0.43-3 (pretty sure it would have been the same with 0.43-4) with the "new" build system by using CXXFLAGS="-std=c++98" for configure.

Now I have another issue:

Pd runs but only if I launch it from the correct folder. That is if I do from a terminal:

cd /path/to/pd-043-3/src
pd

it works (that is where the compiled binary was created; anyway everything holds true if I move it to ../bin/).
But if I do:

cd /path/to/pd-043-3
src/pd

then I get the error:

Error in startup script: couldn't read file "../tcl//pd-gui.tcl": no such file or directory

Not a huge deal, I can write a shell script that cds into the directory and runs pd, but it makes me think that something is not quite right.

I'm also trying and unable to compile the old version of Gem, but I'll open a separate thread about that.

Hi there,

I started dealing with GEM and implemented a very simple patch that simply plays back a video. When I run this patch with pd-gem the playback is all good. But with purr-data the playback stutters since the CPU load is too high. Please find attached screenshots of the patch and atop while running the patch with purr-data and pd-gem.

The pd version with purr-data and pd-gem is slightly different, but I assume that this is not the root cause. So, what is the problem with purr-data and how can I solve it?

Thank you in advance!
Andre

-- purr-data --
Purr-Data 2.19.3
Pd version 0.48.0
GEM version 0.94

-- pd-gem --
Pd version 0.52.1
GEM version 0.94

I think the file I create are blocked by apple security system, since their system automatically tag downloaded binaries to block them... you can type this in Terminal to untag the files:

sudo xattr -cr path/to/Gem

But good news, there is now automatic builds up on deken... Here is the news from IOhannes, who is actively maintaining Gem:

just for the record: since yesterday there's snapshot builds of Gem available on deken.

• this is a snapshot of the current git 'master'. there hasn't been a
  release. things might be more broken then in a normal release (on the
  upside: if you report bug, they are fixed faster than in a normal release)
• there is only a single version "0.94-snapshot". the package will be
  updated whenever a i change something in the git repository. there is no
  turning back (if things worked with yesterday's snapshot, but not with
  the one downloaded today, then you are out of luck)
• Windows: both 32bit and 64bit binaries are available
• macOS: the binary is universal (amd64 and arm64). they should run at
  least on "Big Sur" (i've tested them[*] on Catalina/amd64 and Monterey/M1)
• Linux: there are binaries available, but unlike with Windows/macOS
  binaries, there are no dependencies included. I do advise Linux people
  to just build Gem themselves (or use a distribution that offers packages
  for Gem's git snapshots). this is because on Linux you typically have a
  proper package manager (that allows you to easily install all the stuff
  needed, starting with a compiler), whereas on macOS/Windows you don't
  (unless you count the variants of "app stores" - which I don't).
  the pre-built binaries will most likely not work out of the box on
  your system. (having said that: the binaries where produced on a
  Debian/bullseye system, so if you are running something similar it
  should be possible to just install the missing dependencies with your
  package manager; a good start is to just install the "gem" package that
  comes with your distribution, as this should pull in most dependencies)

gfds
IOhannes

@godinpants said:

I goofed. I fell for it again and upgraded my OS and destroyed GEM. But this time I can't see any solution to getting it running again.

Anyone had luck hacking your way through getting GEM running on Big Sur?

Yeah, my multimedia exam is screwed for one student because of this too.

I'd asked on github and received this suggestion:

i don't really know, but she could try changing the windowing backend, by changing the gemdefaultwindow.pd abstraction in the Gem/-folder and replacing the [gemmacoswindow] (or whatever is there) to one of the other gem*window options installed on your system. (just look out for any externals (.pd_darwin,...) in the Gem/-folder that match the gem*window pattern).
possibly good choices are: [gemglfw3window], [gemglutwindow].

FWIW this is the nail in Gem's coffin for me. Too risky to try to keep it working for a room of 40-50 students.

hjh

FWIW, I don't think it needs to be a replacement for GEM, or pretend to make the interfaces similar to GEM. As noted at the top of the thread, GEM is outdated.

If an obstacle is converting Ofelia's pixel system into something like GEM's normalized coordinates, then... why not simply abandon the idea of normalized coordinates? Unless it's really necessary for practical use. If the only reason to normalize the coordinates was to make it "similar to GEM," I'd say, don't waste time on it.

FWIW, I'm not going to be able to tolerate GEM for another year. Like today -- it took me over two hours to figure out how to extract the alpha channel from pixes. (Like, how many years has GEM existed, and nobody thought it would be useful to have an object to transfer the alpha channel to the main channel of a grayscale pix? Or, if you don't need an object for it, this still seems to me a pretty basic use case... but of course hard to find in the documentation...)

I realize that a set of abstractions on top of Ofelia is not likely to be fully-featured -- but I could cobble together enough Lua to add abstractions myself where needed (and contribute them back), whereas trying to add objects to Gem is impractical (1, my C is not that good and 2, I could build in Linux but not Mac or Windows). Even a partial set of abstractions might be a starting point to get around the kinds of problems I'm facing now, where the existing objects don't quite do what I want and there's not a good way to add functionality.

Otherwise, for this course, I might not have a choice but to jump ship and go to jitter (which some of the students have already done). It pains me to think of switching away from FLOSS but where I am right now is simply not sustainable.

TL;DR Even if the current state is incomplete, would you mind sharing so I could have a look?

hjh

@jb1439 Spaces are a bad idea in path or file names in Pd but that is probably not the reason.
This might be a long thread.
If you don't have it on your computer.... in the Windows/system32 folder, or the Pd/extra/Gem folder for example..... try putting........ this in the Pd/extra/Gem folder.
Unzipped of course.
I doubt it's that actually but it will do no harm

Also..... do you have gem_filmAVI.dll in your Gem folder. It could be in extra/Gem/plugins-disabled in which case it should be copied into the extra/Gem folder.

Also.... which Pd version and are you sure that you have Gem that matches its bits (32/64)
David.

Ubuntu Studio 18.04 includes a package for "GEM: ver: 0.93.3 / GEM: compiled on 2018/02/01 at 21:58:19 UTC."

Current Gem is 0.94.

How do I update Gem on my system?

Deken's most recent Gem for Linux is from 2015 (seriously).

I searched for a PPA but I can't find one for this.

https://packages.debian.org/buster/gem -- compatible with Ubuntu or not?

(The immediate motivation is that, in the last 15 minutes or so, multiple Gem help patches caused Pure Data to crash. I suspect a conflict between new Pd 0.50 and old Gem 0.93...?)

hjh

Purr Data 2.10.0 is now available:

https://github.com/jonwwilkes/purr-data/releases/tag/2.10.0

Changes:

• iem_spec2/spec2_tabreceive_enable~: fix array error handler and set sane default array name value
• fix partconv crashers in bsaylor lib and add perfroutine for array errors
• adaptive/nlms3~: fix typo that caused a double free
• fix lyonpotpourri crashers in dsp, perform and constructor routines
• at least keep the inoperable streamout13~ and streamin13~ from crashing when instantiating
• use some sane default values in ekext/lpreson~ to prevent segfault
• quick fixes to keep cxc/mean~ from crashing when dsp is turned on
• greatly reduce undefined behavior in all dsp objects
• fix hex2dec so that it actually does something useful
• fix #523: crash with manual width adjustment on subpatch
• add ability to change makefile flags for Gem from toplevel makefile
• fix stray bugs detected by obs
• unauthorized/cooled~: increase string buffer size to accommodate the terminating nul character
• unauthorized/cooled~: fix memory access bug trying to concatenate into a string constant
• iemmatrix/mtx_dispersive_dline: add missing void return type
• allow make options like -j8 to be passed to the Gem compilation, which takes awfully long on a single cpu.
• cxc/cxc_split: fix use of un-initialized pointer
• ggee/serial_bird: fix undefined behavior with the ++ operator
• ext13/scramble~: fix header for scramble~
• jasch_lib/detox/detox: reformat for sanity's sake, fix array overflow, undefined behavior
• linux desktop: remove the -rt -audiobuf options from the desktop files.
• linux desktop: change DEFAULTADVANCE to 20 ms for Linux.
• linux desktop: remove leftover TargetEnvironment=Unity lines in menu entries for Purr Data
• linux desktop: add some comments and a few more useful desktop action examples to the main desktop file, so that the user understands how to adjust these if needed.
• linux desktop: replace pd-gui -> nw in the ForceQuit actions, which is the proper name of the GUI program on Linux
• linux desktop: remove useless %U arguments from desktop actions.
• linux desktop: invoke desktop actions via /bin/sh.
• linux desktop: migrate the desktop actions from the ancient Unity syntax to the current freedesktop.org standard
• linux desktop: remove sticky options from the desktop files. For now, keep -rt -audiobuf 20.
• Gem: sync with https://github.com/umlaeute/Gem, QT4L and startup issues have been fixed
• linux: fix the Debian control files once again, since the dependency auto-detection needs a Depends line in there.
• debuild: Support for ARM (e.g., Raspbian)
• update nw-update to nw.js 0.24.4 to fix font issues under Linux
• backport 'add-to-path' from vanilla rev. c917dd19, to make Gem happy.
• usability improvements in the documentation browser.
• switch Gem to the latest from upstream.
• add missing dlls for fluid~ on Windows. Fixes #540.
• Debian packaging: Demote python and fluid-soundfont dependencies, as suggested in #540.
• polish the externals/Makefile clean targets, and delete redundant files in repo
• fix compile options for Xcode 10 - fftease and lyonpotpourri externals.
• update pd-lua to latest upstream.
• fix compile options for Xcode 10 - externals and abstractions.
• fix compile options for Xcode 10.
• ios header needs to be included before base64.h, to avoid compile errors on macOS 10.14.
• fix improper string access in pd_getdirname on Mac.
• fix list cat crasher, update help patch, add missing test abstractions
• get rid of obsolete and unneeded unicap and sndobj dependencies on Linux.
• mark some globals as extern to fix compilation if g_canvas.h is included more than once

Please report bugs here:

https://git.purrdata.net/jwilkes/purr-data/issues

@whale-av, here is a log running pd with -lib Gem -verbose.
tried both 32bit and 64bit pd 0.48-1...

tried ./Gem.m_i386 and failed
tried ./Gem.dll and failed
tried ./Gem/Gem.m_i386 and failed
tried ./Gem/Gem.dll and failed
tried ./Gem.pd and failed
tried ./Gem.pat and failed
tried ./Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pd and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem.pat and failed
tried C:/Users/Raphael Isdant/Documents/Pd/externals/Gem/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.m_i386 and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.dll and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pd and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem.pat and failed
tried C:/Users/Raphael Isdant/AppData/Roaming/Pd/Gem/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.m_i386 and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.dll and failed
tried C:/Program Files/Common Files/Pd/Gem.pd and failed
tried C:/Program Files/Common Files/Pd/Gem.pat and failed
tried C:/Program Files/Common Files/Pd/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.dll and succeeded
D:\\pd-0.48-1.windows.64bit\\extra\\Gem\\Gem.dll: couldn't load
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/extra/Gem/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.m_i386 and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.dll and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pd and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem.pat and failed
tried D:/pd-0.48-1.windows.64bit/doc/5.reference/Gem/Gem.pd and failed
Gem: can't load library```

I've downloaded gem via:
git clone https://git.iem.at/pd/Gem.pd

i then put the Gem directory in the bin directory.

After that inside the Gem folder I ran ./autogen.sh

then:
./configure
./make
./make install

I then also ran:

./make
./make install

...in the source file, (to make sure :S)

i then opened pd from the terminal with:

pd -lib Gem

and the pd window says the following

.....so it looks like thats what you need to do to install gem at least on arch linux, however.

objects such as [gemhead] are recognized but they dont generate a help file?
...and unfortunately [gemwin] isnt recognized as an object at all, confusingly.

May someone interrogate my process here to potentially bring some light on these issues?