A new version of the pd2jack app (v0.4.0), a LibPd <-> JACK client for Linux:
https://github.com/GModal/pd2jack

This release adds OSC IPC, a simple client example, more cmds (over 40), additional patches (some utility patches) and updated documentation.

OSC i/o is handled by pd2jack directly, with options to passthru data to the running patch(es).

There are now over 40 "immediate commands" for controlling pd2jack (and sending data to the patch).

There's an example client (for MobMuPlat) included:

Other native clients are in the works (the holdup on those is mostly about build issues-makefiles, etc).

Yep, if you have Java installed, look in the "CrossPlatformJava" dir, and MobMuPlatEditor.jar should run with a double-click.

I'm also using Ubuntu 20.04. A right-click also shows "Open with OpenJDK Java 11 Runtime".

(I didn't build it, just used the jar from the development package, linked from the "Setup" section of the website.)

Have you tried replacing both JACK & Pulseaudio with Pipewire? I have high-hopes for that, down the road. The artix Wiki has page specific to this: https://wiki.artixlinux.org/Site/PipewireInsteadPulseaudio

On Ubuntu & Debian now, Pulse and JACK can co-exist fairly well. I migrated to the KXstudio way of handling the two, vs Qjackctl, with the bridging controls in Cadence. Three, really, since there's also an ALSA bridge.

Even with JACK & Pulse bridged, my system automatically resets to the onboard sound device for Pulse, vs my default JACK interface (USB). Usually not an issue, but if I'm using Firefox or a video editor, it needs to be explicitly set.

I also use a pair of scripts to kill or restart Pulseaudio, since I'm using JACK 99% of the time. It's not really necessary, but it can reduce CPU load 3-4% :

#!/bin/bash

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

If JACK can't start because some other service has grabbed the interface, try that script before re-configuring (I don't recall if that script alone stops Pulse from respawning, tho).

@Obineg said:

have you ever used a sinc or windowed sinc FIR? or FFT squared filter for that matter? (i.e. allow to introduce latency?)

No, I haven't tried that. I did mess with some fexpr~ FIR filters (again, after upsampling), but the cpu load was massive.

I wish there was a fourth option for [inlet~]: "pad&FIR". The two together are standard for upsampling incoming audio.

I've done a bit with oversampling, and the filter setup in J07 seems to be very efficient, cpu-wise. But you can use what works for your application. ELSE has a LOT of filter objects, too.

I left that part (pre-downsampling), as-is. For oversampling audio input (not audio produced inside the block), post-upsampling filters were more of a judgement call...

Another new release for pd2jack (v0.1.9):

https://github.com/GModal/pd2jack

New with v0.1.9, enabling interactive mode (-i) interprets a "live stream" of parameter pairs (in the console), which are passed on as "param" messages to the Pd patch. These work like the startup "parameter pairs," except for:

• No quotes are required
• Passed in real time during run
• Each pair is terminated with a newline

A stream of pairs might look something like this:

1 89
1 88
1 87
1 86
3 2180
3 2200
3 2221
3 2241
3 2261
4 19

NOTE: this has some cool implications -- a separate GUI application can act as a front-end, and "pipe" data into pd2jack.

So ANY GUI api could be used...just convert any input to parameter pairs and print them to the console. This isn't a crazy as it sounds -- two applications connected with a pipe are separate processes, and if the numeric char strings aren't actually printed to the console (the are not, with pipe), the CPU load is pretty small.

Here's a example of how it's invoked:

./revUI | pd2jack -i -p rev_i.pd

(where revUI is the GUI, and pd2jack is running the "rev_i.pd" patch in interactive mode.)

Simple video demo:

There are other options for IPC with Pd (netsend, netreceive & some custom objects) and piping the console might feel like a hack, but it is simple and quick. An additional method (sockets?) might be added to pd2jack in the future...(yeah, I'm thinking maybe a plugin interface).

It's also been suggested this mode might be useful for people with disabilities. I've also successfully piped the output of pd2jack to a speech synthesis module, sending text via Pure Data's [print] object, as well as any info output in "verbose" mode. Of course, that could probably be done in a normal "headless" Pure Data.

Interactive Mode Special Commands (w/ "@" prefix)

Interactive mode also includes a set of special cmds, for controlling some internal operations. Each of these cmds is preceeded with an "at" symbol (@), to differentiate the cmds from the parameter stream. Here's a list:

• @openPatch <name> : load a different patch into the LibPd space (closes current patch first).
• @closePatch : closes the current patch
• @reopenPatch : reopens the last valid patch (patch can be closed or already open)
• @im_sleepTime <int> : sleep time (ms, 5-500) between data fetches for interactive mode.

Invoking "@reopenPatch" on an already open patch will reload the patch.

I expect more cmds will be added in the future.

A new release for pd2jack today (v0.1.6):

https://github.com/GModal/pd2jack

• This version has improved MIDI support (all RT message supported). Nearly all of the MIDI code was rewritten (and simplified).
• LibPd is now a submodule, and the build process streamlined.
• A Linux binary (zipped w/docs & Pd examples) is available with the release (Building from source is still recommended).

Thanks!

@jyg said:

Great ! Just of curiosity : is the pd~ object supported ?

Nearing a more complete release, I ran a test with the pd~ obj, and (for now) the answer is no. I'm getting the error:

error: pd~: can't stat /pdsched.so
pd~ startup failed

It's likely that functionality lies with LibPd's "multiple instance support." I did try early on to enable that, but there's clearly more to it than simply enabling it (seg fault). So stay tuned, it's something I'd like to run down...

Edit:
Enabling multiple instance support does work now. Progress. Still fails looking for a dynamic library (the other "extras" work without expecting an .so file, and the [pd~] code does build object files.) Hmmm.

Edit 2:
Err, or not. Multiple instance still causing seg faults. To do.

The pd2jack project now has an official release, v0.1.0 (!)

Issues:
- MIDI Sysex msgs larger than 512 are not sent correctly, and will probably send garbage.
- MIDI RT Song Position & Song Select are not implemented (from the encapsulated patch -> output - they should input correctly).

https://github.com/GModal/pd2jack

Thanks!!
DG

@jyg said:

Great ! Just of curiosity : is the pd~ object supported ?

Good question! I haven't tested it, so I don't know. There's a multi-instance build option for LibPd which I'm not using. That has it's own mini-API in the library and isn't directly invoked by any Pd patch code.

But LibPd is Pure Data, with some small caveats. If Pure Data can launch a sub-process, there's a good chance LibPd can as well...

Just opened this repository: https://github.com/GModal/pd2jack

pd2jack is a shell application for running Pure Data patches as minimalist JACK clients, using LibPd. I.E., the patches run "headless" and without a GUI. However, parameters can be passed to the patch from the cmd line.

Up to 16 audio ports and/or 16 MIDI ports can be opened per instance. Ports are defined at startup with cmd arguments, not by the Pd patch.

Example invocation, with three parameters passed to the patch:

pd2jack -p ./pd/rev_ctrl.pd -n MyPatch -s -v 1 -a 2:2 -m 1:0 '1 90' '2 99' '3 0.7'

Currently the code only compiles in Linux (I'm sure the Makefile won't work elsewhere), but I'll try to update that over time.

One way to tell it's a camera issue is the (imperfect) specular reflection on your wooden table -- the LED light reaching the camera from that reflection has the "correct" intensity and plenty of color saturation.

Simple auto-exposure for cameras works by averaging all the tones and adjusting exposure to achieve a "medium gray" overall. If your camera is auto-exposure only, that's a problem -- you need a dark background, but the camera will always lighten the scene (try to average it out to gray).

Does the GoPro work? Those should have manual exposure settings in the camera.

Otherwise, try what whale-av mentioned (and [color 0.25 0.25 0.25] and [pix-threshold] with high values), but those solutions are destructive, data-wise.

It's an intensity thing, rather than a GEM issue -- either the LEDs are too bright, or the automatic exposure in the webcam is compensating for the overall darker background.

Of course you want the video dark, relative to the LEDs. Ideally, you'd have a video camera with manual settings.

@ddw_music said:

(As a silly aside: Speaking as an American, the acronym of graph-on-parent has proven lately to be rather unfortunate, though in Pd's early years, nobody would have predicted it could get so far out of hand.)

I probably shouldn't go there, but I have a similar reaction...

@lysergik
I've done some stuff with Pd/oversampling, although not related to multichannel synths (mono audio streams).

I don't think you're wrong describing the CPU hit -- and that's not really a knock on Pd. It's the nature of all that extra data.

However, definitely try a lower sampling rate; 4X or 8X, and see how that impacts your machine. The J07.oversampling.pd patch ref'd in the manual also illustrates the butterworth.pd coefficients patch, and dropping the low-pass cutoff freq will reduce antialiasing.

Any low-pass filter will help (even lop~), though some will impact your sound more than others. I found biquad~ to be quite useful with incoming audio signals. Sample-resolution tools like fexpr~ will hit the CPU in a major way, but the expr~ obj not so much (it's unfortunately not as useful for filtering). I tend to be limited to vanilla Pd; you may not be.

Working with synth-generated signals within the upsampled block at least reduces some of the overhead, verses upsampled/downsampled streams. It also lends to some sculpting of the sounds without oversampling (the second half of your manual link).

There's much to be said for really targeted and tailored EQ. I like to think much of the 'magic' of commercial software is carefully working around limitations.

I'm unclear on how (or whether) Pd distributes any processes. It might be interesting to try the pd~ obj, and explore "Embedding Pd in Pd" as outlined in Puckette's article on multiprocessors & Pd.

@cuinjune Thanks - bookmarked!

(Ofelia is really pretty amazing, btw.)

@alexandros
If I recall, that install failed until I placed all the OpenFrameWorks source in the ~/OF/ directory. I.e., it wouldn't compile correctly in a subdirectory, only the base of my home dir. That wasn't clear to me from the install docs. And Ofelia source into the ~/OF/addons/ dir.

Deken fails w/Ofelia in my Ubuntu install due to (I believe -- I don't want to try again and overwrite the existing version) a checksum error. Deken does find the external, they just won't install.

You can compile the latest source version, and run Pd locally, in your home dir. Note that it doesn't come without some issues, mostly with paths and externals. But vanilla usually works fine.

I'm also (generally) using the 0.50.2 in Ubuntu 20.04.1 repositories, but that's due to the lengthy process of compiling Ofelia to work with that version (yeah, "breaking something" in Linux is a thing). Deken didn't work for that external.

@Pierre-Guillot
Oops, sorry, when I saw "enhancement" and "removed from to do in 1.0.7" I thought it was done. My bad.

@Pierre-Guillot Thanks Pierre -- all my plugins build and work well with this beta release. Glad you kept the JUCE dialogs for openpanel and savepanel.

Is there any documentation for the new image properties capabilities mentioned in issue #122 (size, anchor, level, etc)?