Hi,

I'm happy to announce the release of AOO 2.0-pre4. Binaries are already available on Deken.

AOO is a lightweight and flexible peer-to-peer audio streaming and messaging solution. It allows to send audio and messages in real time and on demand between arbitrary network endpoints, not only in local networks, but also over the public internet!

The underlying C/C++ library can be easily embedded in host applications or plugins and even runs on embedded devices, such as the ESP32.

For more information, see the AOO website (https://aoo.iem.at).

I have also written a short article about AOO: https://www.soundingfuture.com/en/article/aoo-low-latency-peer-peer-audio-streaming-and-messaging

Note: technically this is still a pre-release, but the Pd external and the network protocol can be considered stable. (They haven't changed since v2.0-pre3.)

Please report any issues at https://git.iem.at/aoo/aoo/-/issues

Have fun!

Christof

but it won’t load any Linux vsts (.so)

Have these plugins been compiled for the Raspberry Pi (ARM)? I personally know people who successfully use [vstplugin~] on the RPi, so it should be possible, but the plugins must have the right architecture.

Now it says it can’t bridge the architecture… terminal says no host exists that can bridge to i386

Did you build the wine host for [vstplugin~]? (See the README for instructions.) If the built-in wine host doesn't work, you can try external wine bridges like yabridge.

Hi everyone,

I have just released [vstplugin~] v0.6.0! Binaries are available on Deken (search for "vstplugin~").

The most important new feature is support for multichannel signals: a single input or output signal can now contain multiple channels. This is particularly handy for spatialization plugins with many channels, such as higher-order ambisonics. Not only does it save you from drawing lots of patch cords, it also allows you to change the channel count dynamically! For example, you can now freely change the ambisonics order without rewriting your patch.

IMPORTANT: previous versions would hide certain (non-automatable) parameters in VST3 plugins. This has been fixed, but as a consequence, parameter indices might have changed. [vstplugin~] prints a warning for every plugin that is affected by this change!

Here is the full changelog: https://git.iem.at/pd/vstplugin/-/releases/v0.6.0

Please report any issues at https://git.iem.at/pd/vstplugin/-/issues

Have fun!

Hi,

here's a pre-release for [vstplugin~] v0.6 - an external for running VST2 and VST3 plugins inside Pd.

Binaries for all platforms are available on Deken (search for "vstplugin~").

The most important new feature is multichannel support (requires at least Pd 0.54)!

This is particularly handy for spatialization plugins with many channels. For example, a single signal may now contain a full 64-channel ambisonics bus. With the IEM plugins (https://plugins.iem.at/) you can even change the channel count dynamically and the plugins will automatically adjust the ambisonics order.

NOTE: previous versions would hide certain (non-automatable) parameters in VST3 plugins. This has been fixed, but as a consequence parameter indexes might have changed. [vstplugin~] prints a warning for every plugin that is affected by this change!

Here is the full changelog: https://git.iem.at/pd/vstplugin/-/releases/v0.6-test1

As always, please test and report any issues to https://git.iem.at/pd/vstplugin/-/issues.

Christof

I don't understand why [send~] needs the channel count specified while other audio objects just "know"... that seems strange.

The reason is that a matching [receive~] might be scheduled before the [send~]. At this point, the [send~]'s "dsp" method wouldn't have been called yet, but [receive~] already needs to know the channel count. Note that you can still change the channel count dynamically with the "channels" message.

As a side note: with [throw~] and [catch~] the relationship is reversed: [throw~] does not require a channel count, but [catch~] does.

There are still bugs in multichannel though.

What about reporting them?

There's an experimental 64-bit version of Pd

This is really orthogonal to 64-bit OSC timetags. This version just uses 64-bit floats as the underlying type for float atoms and samples. It does not magically implement the missing OSC typetags. Also, let's please call this the "double-precision" version, as "64-bit" typically refers to the CPU architecture.

Actually, there is no reason why Pd's [oscformat] and [oscparse] could not support the h (= int64) and d (= float64) typetags for sending/parsing OSC message. Of course, single-precision Pd would need to round the values down to 32-bit floats, but double-precision Pd could keep the precision (at least for 64-bit floats; 64-bit integers may still lose some lower bits when converted to 64-bit float atoms).

TL;DR:

"Blocksize": hardware buffer size
"Delay": extra latency

Then, in the Pd audiosettings, you set the "Delay (msecs)". This sets the size of the buffer between Pd and the soundcard.

This is not true. (I don't blame anyone for making this mistake, as this is not obvious unless you know the Pd internals.)

By default, Pd uses the so-called "polling scheduler". The message system and DSP run in a dedicated thread which communicates with the actual audio callback via a (lock-free) ring buffer. "Delay" effectively controls the size of that buffer. It adds extra latency on top of the hardware buffer size.

The actual hardware buffer size is always controlled by the - confusingly named - "Blocksize" parameter. (Pd's internal blocksize is fixed at 64 samples.)

Alternatively, Pd may use the so-called "callback scheduler", which is enabled by the "Callbacks" option in the audio settings. In this case, the message system and DSP run directly in the audio callback and latency is only affected by "Blocksize". (This option has disappeared in Pd 0.54, but will likely reappear in the future after some scheduler bugfixes have been applied. See https://github.com/pure-data/pure-data/pull/1756.)

Tip: If you run Pd with the default "polling scheduler", then you should set "Blocksize" as low as possible and control latency with the "Delay", as it offers finer granularity.

@60hz The next version will have macOS ARM binaries. In the meantime, you can use this snapshot from the develop branch: https://git.iem.at/pd/vstplugin/-/jobs/55565/artifacts/download?file_type=archive

(If the link stops working, go to https://git.iem.at/pd/vstplugin/-/pipelines and download the "package" artifact from the latest "develop" pipeline.)

Hi,

In the Changelog of vstplugin~ v0.5.4 it says ARM compilation is fixed though.

I think this refers to https://git.iem.at/pd/vstplugin/-/commit/ec1bb344512f1de6819cd2ca06fbfde793393326.

However, ARM support on Linux has been fixed only recently (https://git.iem.at/pd/vstplugin/-/commit/8cbdb1a971e2f4ac48953b9bc7be6370d42ea50f) and not merged into master yet.

Try the latest develop branch, people have successfully built it on RPIs.

@seb-harmonik.ar said:

@Obineg all of pd vanilla runs on 1 thread (well, the 'core' non-wish process anyways)
Message processing is simply interspersed w/ audio processing.

Almost. Pd does use a single thread for DSP and message processing, but this is not the same as the audio callback (unless "use callbacks" is enabled), so you have (at least) two threads.

Side note: In Pd, the audio callback does almost no work; it just reads/writes samples from/to a ringbuffer and returns. Pd's main thread waits on the ringbuffer (see sys_send_dacs), so it is indirectly (asynchronously) driven by the audio callback.

I've just put the vstplugin folder into the /extras folder

If by "vstplugin folder" you mean the source code, then this certainly doesn't work.

I have no experience with compiling, so was hoping to avoid that

Well, you definitely need binaries. But there is a way to avoid compiling from source: use one of the pre-built binaries https://git.iem.at/pd/vstplugin/-/releases

Hi!

I was trying to get this to work in Purr Data, but don't seem to have had any luck.

"It does not work" is not all too helpful for an error report Can you give more details?

Also, please consider opening a ticket at https://git.iem.at/pd/vstplugin/-/issues.

PSA: comport v1.2 has been released and is available on Deken. This issue should be resolved now. Please test!

would use their own selectors and that selectors would be a thing, but they are not and it does not help in any way

Selectors are used all the time. Every method - apart from float, symbol and pointer methods - starts with a selector. For example, if you send [set foo( to [tabwrite], set is the selector.

another option is [iem_receive] from iemlib.

This feature seems trivial on surface, but it is really not. If implemented naively, it can crash Pd under certain circumstances. For a technical discussion, see https://github.com/pure-data/pure-data/pull/604. Making it safe would require some changes to Pd internals, see https://github.com/pure-data/pure-data/pull/849.

Hi,

here's a new bug fix release for [vstplugin~] - an external to load VST2 and VST3 plugins on all platforms. Please upgrade!

Binaries can be found on Deken (search for "vstplugin~") or here: https://git.iem.at/pd/vstplugin/-/releases.

Most important changes/fixes:

• fix crash with bridging + multi-threading (regression introduced in v0.5.1)
• bridge/sandbox: allow to write large presets
• cmake: add NATIVE option for native code generation
• cmake: support Apple M1 + x86_64 plugin bridge (see the README for build instructions); no official binaries yet
• new update message, sent when several parameters have changed at once

Full change log: https://git.iem.at/pd/vstplugin/-/releases

As always, please report any bugs at https://git.iem.at/pd/vstplugin/-/issues

Have fun!

Christof

I guess there's no other way.

Here is the PR: https://git.iem.at/pd/comport/-/merge_requests/1

In the meantime, you can grab the following branch and build from source: https://git.iem.at/ressi/comport/-/tree/input-fix

Martin Peach (who wrote [comport])

[comport] has been written by Winfried Ritsch.

Funnily enough, someone else has already brought up this issue in the past (https://lists.puredata.info/pipermail/pd-list/2019-05/125271.html) and I even came up with a fix, but then forgot to make a PR . I found the git branch with the fix on my laptop, so I can do that later this day. Will post a link to the PR here.

Hi,

here's a new bug fix release for [vstplugin~] - an external to load VST2 and VST3 plugins on all platforms:

Binaries can be found on Deken or here: https://git.iem.at/pd/vstplugin/-/releases.

This release fixes a critical bug where [vstplugin~] would fix crash when switching samplerate or blocksize while a plugin is loaded. Even worse, Pd would also crash when loading a plugin with [loadbang] or as a creation argument at samplerates other than 44.1 kHz.

Please upgrade!

As always, please report any bugs at: https://git.iem.at/pd/vstplugin/-/issues

Christof