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

@Obineg said:

that´s why tapping buffers do exist: because you cant do the same with the regular buffer object.

Actually, in SC you can do it with a regular buffer, because it has a Phasor suited to the task (and you use LFSaw for a pd-style phasor~).

using a tapping buffer is probably more work (think of all the logic needed to find the right record position, size the buffer, restart the next round)

I think all that's required is that the delay line max size is longer than one cycle -- bang a timer once at the start, and once for the second cycle, and let this set the delay time. Then it runs on autopilot after that (at least for the Lucier piece).

(no chance to save your work in progress?) compared to using simply 2 different buffer objects alternately.

That's fair -- if you need to save an intact buffer, two buffers would be the way to go.

hjh

Hi there, I'm working on a project that involves streaming audio from an AVPlayer video player object into libpd. For the process loop of the tap, I used PdAudioUnits render callback code as a guide; but I realized recently that the audio format expected by libpd is not the same as the audio coming from the tap — that is, the tap is providing two buffers of non-interleaved audio data in the incoming AudioBufferList, whereas libpd expects interleaved samples. Does anyone know of a way I can work around this?

I think that I need to somehow create a new AudioBufferList or float buffer and interleave the samples in place; but that seems expensive to me. If anyone could give me some pointers I would greatly appreciate it!

static void tap_ProcessCallback(MTAudioProcessingTapRef tap, CMItemCount numberFrames, MTAudioProcessingTapFlags flags, AudioBufferList *bufferListInOut, CMItemCount *numberFramesOut, MTAudioProcessingTapFlags *flagsOut)
{
    OSStatus status = MTAudioProcessingTapGetSourceAudio(tap, numberFrames, bufferListInOut, flagsOut, nil, numberFramesOut);
    if (noErr != status) {
        NSLog(@"Error: MTAudioProcessingTapGetSourceAudio: %d", (int)status);
        return;
    }
    
    TapProcessorContext *context = (TapProcessorContext *)MTAudioProcessingTapGetStorage(tap);
    
    // first, create the input and output ring buffers if they haven't been created yet
    if (context->frameSize != numberFrames) {
        NSLog(@"creating ring buffers with size: %ld", (long)numberFrames);
        createRingBuffers((UInt32)numberFrames, context);
    }
    
    //adapted from PdAudioUnit.m
    float *buffer = (float *)bufferListInOut->mBuffers[0].mData;
    
    if (context->inputRingBuffer || context->outputRingBuffer) {
        
        // output buffer info from ioData
        UInt32 outputBufferSize = bufferListInOut->mBuffers[0].mDataByteSize; // * 2 solved faint avplayer issue
        UInt32 outputFrames = (UInt32)numberFrames;
//        UInt32 outputChannels = bufferListInOut->mBuffers[0].mNumberChannels;
        
        // input buffer info from ioData *after* rendering input samples
        UInt32 inputBufferSize = outputBufferSize;
        UInt32 inputFrames = (UInt32)numberFrames;
        UInt32 framesAvailable = (UInt32)rb_available_to_read(context->inputRingBuffer) / context->inputFrameSize;
                
        //render input samples
        
        while (inputFrames + framesAvailable < outputFrames) {
            // pad input buffer to make sure we have enough blocks to fill auBuffer,
            // this should hopefully only happen when the audio unit is started
            rb_write_value_to_buffer(context->inputRingBuffer, 0, context->inputBlockSize);
            framesAvailable += context->blockFrames;
        }
        rb_write_to_buffer(context->inputRingBuffer, 1, buffer, inputBufferSize);
        
        // input ring buffer -> context -> output ring buffer
        char *copy = (char *)buffer;
        while (rb_available_to_read(context->outputRingBuffer) < outputBufferSize) {
            rb_read_from_buffer(context->inputRingBuffer, copy, context->inputBlockSize);
            [PdBase processFloatWithInputBuffer:(float *)copy outputBuffer:(float *)copy ticks:1];
            rb_write_to_buffer(context->outputRingBuffer, 1, copy, context->outputBlockSize);
        }
        
        // output ring buffer -> audio unit
        rb_read_from_buffer(context->outputRingBuffer, (char *)buffer, outputBufferSize);
    }
}

@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

Following a previous discussion < https://forum.pdpatchrepo.info/topic/12905/bang-bangs-before-the-end-of-a-dsp-block-at-startup > i'll post there a series of examples to explain what's going on under the hood with reblocked subpatches. It is based on experiments i done with my fork, but AFAIK it is exactly the same in Pure Data (there are minor differences but IIRC it doesn't change global behaviour). Please correct me if you thing something is wrong in order to avoid to make things more impenetrable in the future that it is already now.

• Up: [block~256]
• Down: [block~ 32]
• Downsample: [block~ 32 1 0.5]
• Upsample: [block~ 128 1 2]
• Overlap: [block~ 128 2]
• Overlap: [block~ 512 4]

I do that because i always forget how it is done, and must bang my head again and again.

Thus: first reblocking up (i.e. [block~ 256])!

[---a]  !  [---A] #0
    ^       ^
[b---]     [---A] #1
 ^           ^
[bc-a]     [---A] #2
  ^           ^
[bcda]     [---A] #3
   ^           ^
[bcde]  !  [BCDE] #4
    ^       ^
[fcde]     [-CDE]
 ^           ^
[fgde]     [--DE]
  ^           ^
[fghe]     [---E]
   ^           ^
[fghi]  !  [FGHI]
    ^       ^

a b c d e f g h i / - - - A B C D E F

// [block~ 256]

BLOCK FREQUENCY+1
BLOCK PERIOD+4
INLET SIZE+256
INLET WRITE+192
INLET HOP+256
OUTLET SIZE+256
OUTLET HOP+256

#+0#        // First tick.

P+192/+64   // Prologue: write 64 samples at 192 of the buffer in.

R+0/+256    // Read 256 samples from the buffer in to be processed.
W+0/+256    // Write the result in the buffer out.

E+0/+64     // Epilogue: read 64 samples at start from the buffer out.

#+1#

P+0/+64     // Prologue: write 64 samples at start of the buffer in.
E+64/+64    // Epilogue: read 64 samples at 64 from the buffer out.

#+2#

P+64/+64
E+128/+64

#+3#

P+128/+64
E+192/+64

#+4#

P+192/+64

R+0/+256
W+0/+256

E+0/+64

#+5#

...

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```