Celebrating the 10th anniversary (yikes, a whole decade of my repository today (February 21st 2026), I have wrapped an update for Cyclone. Check https://github.com/porres/pd-cyclone/releases/tag/cyclone_0.9.4 and find binaries in deken for mac/linux/windows and raspberry pi. And please let me know if you have any problems with these binaries!

Last year I made a minor update (0.9.3) a couple of months after the 0.9.2 release, but I never formalized a release update with binaries into deken and an announcement. Let's just skip that, but here's the changelog for 0.9.3 while we're at it:

• Fixed bug in [unmerge] where it wouldn't deal well with mixed floats and symbols in a list
• Fixed crash and resize bug in [zl.group]/[zl.stream]

This one made it into the PlugData 0.9.2 release recently, by the way.

I was actually hoping I'd have a 1.0 right now to celebrate my 10 years involved with Cyclone, but I failed miserably. The plan is to release that along with PlugData 1.0 as well, whenever that happens (some updates to [mtr] is what's missing for me to call it 1.0.0 already, by the way).

So anyway, here's 0.9.4!

Many cosmetic changes in this one, which I'm kinda proud of. I did finally add a menu entry so people can disable the object browser plugin, while I also improved it to include browsing in more nesting level depth.

So, if you think my beautiful and hard work designing a nice plug-in browser is not welcome, you can go to Preferences=>Cyclone-Browser-plugin and disable it.

Other more cosmetic changes are that I made some updates to the text editing window of objects like [coll]. One of the things is that it now uses Pd's "theme" colors in it (so Pd >= 0.56 is needed)! I also made some other changes like being able to use CTRL+S to save and CTRL+W to close the window. Also, typing and editing it on the window now marks the patch as dirty if you have the "@embed" flag enabled (same is true for [table]).

There are some other bug fixes, and here's a full changelog if you're curious about all the details.

CHANGELOG:

• We now have a preferences menu to disable the browser plugin! See Preferences => Cyclone-Browser-plugin. If you always hated this, disable it and save the setting. The browsing plugin is now also better organized with more nesting levels.
• [prob] removed the functionality for viewing the data because the MAX original doesn't have it and it makes no sense, cause we can't edit it and save it and you can already see the data with "dump" (which prints on the terminal window). When embedding, now we also have a dirty flag when setting data, just like [cyclone/coll] and [cyclone/table] (even though the MAX original doesn't do it).
• Text Editing Window Improvements: colors now adapt to Pd's theme (so >= 0.56 is needed) and font size also adapts to patch's font size. Allow ctrl+s to save and ctrl+w to close the window. This affects [cyclone/seq], [cyclone/coll], [cyclone/table] and [cyclone]/[capture~] (again, [cyclone/prob] doesn't have it anymore). Also make manually editing the window and saving it sets the dirty flag on the patch for [coll] and [table] (and not only with changes via messages as before).
• [coll]/[table] improved dirty management as it wouldn't mark dirty if the owning canvas wasn't visible (which was a stupid hack to not mark it as dirty when loading the patch).
• [coll] now forces a correct order of args and deals with 0/1-length list messages.
• [table] fixed trying to open the name argument as if it was a file. Now resizing updates the editing window if it is opened.
• Improved [cross~], it is now a 4th order filter (even though Max claims theirs is a 3rd order filter). The last one didn't sound good when adding the lowpass and highpass output.
• [scope~] improved resizing handle mechanism
• [comment] fixed "mouse release bug" annoying error and initialization with a zoomed patch.
• Fixed many typos in the docs.
• Improved github actions and added Raspberry Pi binaries
• Fixed CMake build for compiling a single binary

Cheers
Alexandre Torres Porres

Here's a revised version, there were minor mistakes...

see:
triple-nested-allpass-2.pd

here's the CSound triple nested example from that tutorial translated to Pd using objects from ELSE.

see
triple-nested-allpass.pd

from the referenced nested allpass structure, this is what I make of it...

see nested-allpass.pd

Hi, I have a deep section on filter theory in my tutorial, and how to build some reverbs with it and comb filters. It is part of the ELSE download!

Screenshot 2026-01-13 at 19.48.07.png

Also, note that [rev1~] uses a series of allpass filters in Vanilla, but not a nested one. Give me a minute and I can try and make nested ones.

@Ice-Ice by the way, please don't use illegal arguments in inlet/outlet objects, it's not a good practice.

I am reading about reverb algorithms and I came across the concept of nested allpass filters.

Here's an illustration of a regular allpass filter:

And here's a nested allpass structure:

source: http://gdsp.hf.ntnu.no/lessons/6/33/

I used those illustrations as well as H14.all.pass from the audio examples as the basis. But I am not sure I am doing this right at all....

Here's a vanilla allpass I made:
vanilla_allpass~.pd

And here's a nested allpass using the above abstraction:
nested_allpass~.pd

Is this a proper nested allpass? If not, where am I going wrong? As you might guess, I don't fully understand [rzero_rev~] and [rpole~].
Cheers

@dreason said:

Why can I access the contents of the msp folder using file glob in Puredata, but not in Plugdata.

The way to test something like this is to fall back to the simplest possible case and look for differences in behavior.

If I create a patch:

[symbol *(
|
[file glob]
|
[print]

-- note here *, not */msp -- since */msp isn't giving any useful data in plugdata, it's not useful for troubleshooting. Making it the most permissive possible search should at least give more information.

Now, if I run this patch before saving, plugdata prints the contents of my user home directory.

Then, I save the patch into a different location and run it again. Now it prints the contents of the location where the patch was saved. oops! It's not! It's the first location that showed up in the plugdata file browser when I hit save. Yeesh. That's weird.

OK, so I open that patch in Pd 0.55.2 with the expectation that it will also print the contents of the patch's location.

Instead, it prints the contents of the home directory.

Now, which one of those is correct? Both of those seem off to me.

In general, if a file path is not written out in full (e.g. /home/xyz/msp/* or c:/Users/xyz/etc/etc), Pd is supposed to resolve it relative to the patch's location, and, failing that, check other locations defined in Paths preferences. In this case, plugdata is following the precedent of other Pd vanilla objects, while Pd is breaking its own precedent by reverting to ~/*. -- [file] help explicitly says symbol * should match "all files/directories in this directory" but it doesn't do that on my machine = bug.

But plugdata's file location isn't consistent (seems to depend on some undefined user actions in the file browser).

So they're both question marks for me.

hjh

@FFW As far as I am aware there is no good way to determine how deeply nested in the patch an abstraction is. In the past when I have needed this I have used [canvasindex] since it produces no output if toplevel, something like this:

Possibly warrants a feature request on the pd github, results may happen quicker with an iemguts feature request but I am not sure if umlaeute has any interest in extending the features of iemguts but he is quick about dealing with bugs. Probably will not be a feature of vanilla anytime soon since the official way to deal with such things is [namecanvas] and named canvases which covers most use cases. With how things currently stand, numerical depth is more suited to the iemguts workflow than the pd workflow,

Edit: Not completly certain I understood you use case. Do you actually need to determine depth? Is the issue nested canvases? If depth is constant then [iemguts/sendcanvas] will solve your issue. I suspect my post was going the wrong direction and you don't need to worry about depth?

responding to myself here ... it's possible to iteratively append data to a top-level array with purest_json (which avoids the restriction to symbols of MAXPDSTRING size).

that's not possible for nested keys though (which is a requirement in my case). i changed the purest_json code now so that i can add to nested keys via messages like array LoudspeakerLayouts.Loudspeakers $1. not sure if that's the "right" way and i'd still be curious if other people see better options in Pd for it!

@whale-av thank you so much. I have contact with the devs but I try to wait asking for favours until I have a decent understanding... as I do not want to strain you guys too much either... its a balancing act.

Unfortunately mrpeach is not available through deken, says "no matching packages for your architecture". Im on a Mac M2 with 12.5.1 Monterey that comes with the robot.

Status at the moment:

I can trigger from the browser and from terminal/zsh with curl.

I have not managed to get [netsend] to work. Tried some combinations with list and symbol. If using tcp I lock out terminal and browser triggering on that port/socket(?) (8000) . Using [netsend -u] (UPD) allows me to continue using terminal/zsh or the browser for triggering. My conclusion is that it would work if could format the message in the right way. But I do not know how the message looks when/if it arrives at the Ikaros WebUI. Can I monitor this in some way?

Now I will try using [command] to see if that works.

EDIT:
This works!! thanks @oid for getting me into [command]!

Now the next step will be to try to control parameters.

My goal is to be able to change the slider parameters of the robot/web ui from Pd by some sound process on the same computer locally. So no plans for connecting over internet at the moment.