Helix-style multipath performance fork: feedback and upstreaming plan

[diamondsea11]

Hi Robin,

First, thank you for PiPedal. I have been testing a performance-oriented experimental fork for Raspberry Pi OS Lite and an iPad-based live workflow. The work was inspired by Helix, Quad Cortex and Anagram routing/control concepts, while retaining PiPedal as the audio host. I'd like to state for transparency reasons that I don't have in-depth programming skills and relied on Claude Code, Codex and some patience to create this. The initial idea was only to be able to have access to all in- and output of my babyface pro fs and not just L+R.

The current integration branch includes:

• dynamic multichannel ALSA detection and interface-derived input/output choices;
• up to four independent paths, hardware routing, parallel sends/returns and drag-to-create parallel splits;
• input and output terminal editors, including a linked-channel input noise gate with threshold and decay;
• NAM Gateway-style capture calibration with per-interface input calibration profiles;
• a touch-oriented plugin browser, categorized/colored blocks, block copy/paste/duplicate/delete and a Gig view;
• expanded MIDI actions, per-snapshot assignments, controller profiles and an event/action monitor;
• graphical Global EQ and tailored control layouts for several LV2 plugin families;
• host compatibility work for numeric LV2 patch properties, bounded block length and JUCE-style sidechains.

This is deliberately not being proposed as one giant pull request. The integration branch touches roughly 200 files and combines audio-engine, preset-schema, UI, host-compatibility and bundled-plugin work. I would like to contribute useful pieces back as small, focused PRs based on the current upstream branch.

Branch: https://github.com/diamondsea11/pipedal/tree/feature/multipath-v1

Change inventory: https://github.com/diamondsea11/pipedal/blob/feature/multipath-v1/docs/ForkChanges.md

Validation roadmap: https://github.com/diamondsea11/pipedal/blob/feature/multipath-v1/ROADMAP.md

Proposed PR breakdown: https://github.com/diamondsea11/pipedal/blob/feature/multipath-v1/UPSTREAMING.md

The branch builds natively on arm64 and is running on a Raspberry Pi 5 with an RME Babyface Pro FS. TypeScript production builds and the focused multipath, preset roundtrip and routing tests pass. Physical loopback latency, complete foot-controller acceptance and testing on a second multichannel interface are still called out as pending.

Would you be open to reviewing selected pieces, and is there a particular starting point you would prefer? My suggested first candidates are the narrow ALSA multichannel detection fix, generic numeric LV2 patch-property support, or block editing/touch interactions. I am also happy to adapt the implementation to fit PiPedal architecture and UI conventions before opening any PR.

Thanks again for making the project available.

[diamondsea11]

I have now published the exact tested ARM64 build as an experimental prerelease, so the current integration can be evaluated without rebuilding it first:

https://github.com/diamondsea11/pipedal/releases/tag/pipedal-2.0.110-codex21

The .deb contains the modified PiPedal server, production web UI and bundled TooB Amp build. It was built and installed back onto the Raspberry Pi 5 reference host, where the web service and 12-channel ALSA session started successfully. The package targets Raspberry Pi OS Lite / Debian 13 (Trixie), arm64; it is not compatible with Bookworm because it uses Trixie t64 dependencies.

The separately installed Dragonfly, Calf, LSP, Chow/Airwindows and Dusk plugins are intentionally not redistributed in the package. A plugin inventory and SHA-256 checksum are included as release assets.

[diamondsea11]

A few screenshots from the current codex21 build running on the Raspberry Pi 5, captured at an iPad Pro landscape viewport:

Signal chain and calibrated NAM view

The chain uses category colours, interface routing in the header and the tailored TooB NAM view with capture/interface calibration.

Interface-derived input routing and input gate

The input terminal exposes the actual interface channel (IN 3 mono) together with the linked-channel gate, threshold, decay and input trim.

Graphical Global EQ

Low/high cuts can be dragged directly; cut slopes, shelves, mid frequency/gain and Q remain available as precise controls.

Snapshot-aware Control Hub

Blocks expose a predefined parameter list with units and semantic ranges before creating a MIDI assignment. Base and snapshot-specific actions are edited in the same view.

Touch-oriented Gig View

A simplified performance surface provides large snapshot, path mute and effect bypass controls.

[rerdavies]

Ok. I guess this works. I'd prefer to do this via a back-channel direct conversation though. My personal email: rerdavies@gmail.com That might be a better place to have this discussion. I am just back from a back-woods vacation, with no real cell connection or internet connection to speak of, so I am still catching up. Appologies for not getting back to you promptly on all of this.

There are a lot of things I would absolutely like to pull into PiPedal mainline. And a lot of things we need to discuss before coming up with a strategy to do so.

First things first, though. Just so that I can get a sense of the code that I'm reviewing. I am not at all averse to AI. But answers to the following question will determine how carefully I need to review code in pull requests (and what I need to pay particular attention to).

1. What are your developer credentials. (if any). (Professional/amateur, years of experience, &c).
2. To what extent are these features vibe-coded (does extraordinary things, but requires careful review, and tends to do poorly on UI implementations), or AI assisted (not really a concern).

I very much like the restyling, especially the restyling of control groups, and would definitely like to pull that into PiPedal mainline. Are these copying Helix UI? I have a bit of a problem with slavishly copying Helix UI. But I do like the square groups, particularly.

Handling of JUCE-style controls: Definitely interested! Some concern over whether the TTL parser I'm using will present the controls in random order (I think it will. I think it hashes keys). TTL makes no ordering guarantees; and the JUCE authors SHOULD have added indices to their control! Before I pull this in, I need to figure out whether drobzilla's TTL parsers will preserve the order of the JUCE controls. Also generally true, in the few cases where I have stumbled across JUCE-generated plugins, that they don't really work well without the JUCE custom UI layouts. I will conceded that the plugins that you have provided custom layouts for are good enough that SOMETHING needs to be done to support them.

Patching of LV2 categories. Sure! LV2 plugin categories are an unholy mess. I'd like to see what you have. Some concerns about translation and internationalization, although, truthfully, it is unlikely that the PiPedal UI will ever be translated.

Custom layouts for various plugins (Chow Tape, Calf, Dragonfly, Dusk Reverb): definitely interested. All superb plugins, seems reasonable to do what I can to enable them. (And I suspect part of that will be providing custom layout for the JUCE controls).

Handling of sidechains. Would definitely take a pull request for this. However, your git fork seems to suggest that you don't yet support selection of output of particular plugins. Is that right? How about a send from a lower branch to an upper branch of a split (which would require re-ordering of plugin execution, in order to prevent 1 buffer delays in the send)? Is that implemented? At any rate, I am definitely interested in pulling support for sidechains, as long as the implementation is complete.

Suspended processors receive a short dry warm-up before a smooth S-curve bypass crossfade: I don't think I want this. I'd prefer to just keep all processors running, which allows crossfading of A/B splits (and sort-of preservation of reverb tails). (By the way, I'm pretty sure similar-structure presets preserve reverb tails already, in exactly the way that snapshots do. If they don't that would be a bug. let me know. On a Pi 5 or higher, there is more than adequate processor power to just keep everything running; and the advantages of not suspending processors seem, to me, to be 100% worth it. Specifically, it means that everything can be cross-faded, and avoids ducking (which you have to do with the S-curve approach). I suppose it could be a Setting. But doing so would be far down my list of priorities at present. It's adequate for Pi 4; and not at all required on Pi 5's and x86 systems.

S24_LE capture/playback scaling. If it's broken, I definitely need a fix for this please.

Align TooB Neural Amp Modeler calibration and quality defaults with the NAM Gateway workflow. . Yes. I would take this. There has to be careful versioning of presets to ensure that old presets are not broken. (I can give you suggestions on how to best do this, I think).

Support up to four independent signal paths with selectable hardware inputs, mute, pan and level controls. My concern: it makes patches device-specific, and therefore non-sharable. The long term roadmap for pipedal is to handle this through the current routing dialog. There were SUPPOSED to be a set of routed plugins for the Aux channel specifically for things like microphone channels. The initial attempt to implement this came unglued, and got backed out because I had to hit a deadline for NAM A2 support. But it will happen. (I have a better approach in mind for a second attempt at implementing this). Not interested in this.

A better approach (I think), is to have separately configured signal paths for a main and aux channel. (And an aux2 channel if you absolutely MUST have this feature). I think this makes more sense than your implementation, because it allows users to have a microphone channel (for example) whose configuration does NOT change when you change presets, and does NOT require every single preset to have a configured microphone channel.

And as a part of that cluster, a GLOBAL preset that potentially include pre- and post- EQ (of your choice), a noise gate of your choice, and, potentially post reverb.

Each with their own banks of presets.

Responsive UIs (UIs that alter their layout depending on screen size). I have general concerns about responsive UIs. A primary feature of PiPedal is that it can be used on a phone, with formats as small as 400x800, or 800x400 (just barely). As I'm sure you have noticed, the UI is HIGHLY responsive, adapting itself to a wide range of screen formats. While it may make sense to have an icon/title bar on a large-format tablet, or desktop browser, it isn't going to work on an 800x400 (landscape) phone display. If your UIs have been designed specifically for an Apple tablet, that's going to be a problem across the board. Let me know whether you have made any provisions for responsive UIs. (Pretty sure I will take the custom layouts anyway, and add responsive UI support as required if you have not).

Added gestures: I have some serious concerns here. PiPedal was originally written using Android UI conventions (with very minor allowances for desktop conventions). Android discourages use of context menus (maybe even outright forbids them). And they do tend to be problematic in landscape layouts, where only 4 to 6 menu items are visible without scrolling. Many of the added features seem to use extended gestures. (For example, I cannot imagine how you do multiselect without breaking drag-to-scroll). As part of that, long-press has been reserved to launch the plugin browser. (Double-click is not a standard gesture in Android UI conventions). I do have second thoughts about that. And I'm very tempted to use double-tap as a standard gesture. (Currently double-tap is provided for desktop browsers, and usually has the same effect as long-press in small touch displays). I'm not that familiar with Apple touch UI conventions. I rather suspect that some of the features you have implemented introduce breaking changes. I'm inclined to agree that desktop browsers (and perhaps large tablets) need context menus.

Fwiw, Microsoft UI guidelines advise AGAINST context menus. Their reasoning: according to usability studies sophisticated users love them; ordinary users (75% of all users) NEVER use them. And, Microsoft UI guidelines ABSOLUTELY require that anything on a context menu must be accessible via other means. I find this a bit heartbreaking, since I pretty much exclusively use context menus when they are available. But I'm a programmer, so what do I know about ordinary users (original Apple UI Guidelines).

This is, admittedly a problem in my current UI. There aren't any more places to tuck away new menus and features and buttons on an 800x400 display. And the copy and paste feature that was added recently is in an outrageously inappropriate place. I do think that I need to rethink the overall UI conventions. But it seems extremely dangerous.

Discuss your UI conventions, please.

I haven't tried the "Control Center" yet. I need to spin up a new image, because I'm concerned about contaminating my dev machines with incompatible presets. But I will. It sounds promising. And I will concede that the current "MIDI Mappings" menu is going to have to evolve into something that sounds like your "Control Center" very soon. Just back from vacation, and catching up, it may take me a day or two to get there. Let's come back to that. (If you're planning on publishing the fork widely, you may want to consider moving YOUR /var/pipedal/presets directories into a different one, in order to avoid the incompatible preset problem. Take a look at the code that handles upgrading of presets; that might be a good place to copy factory and existing presets into a dedicated directory for your fork.

The Gigging UI: need to take a look at it. There's definitely a roadmap for the current "Performance" UI -- at a minimum, the ability to swap Snapshot buttons for bindable controls. Which probably maps onto your "Control Center" much more nicely. More on this later, once I get a running instance.

All in all, it LOOKS impressive as heck. There are DEFINITELY pieces I want to pull back into PiPedal mainline. And also a few pieces that I don't think I can pull into PiPedal mainline.

So I do think we need to have a discussion about what can and should be pulled back into mainline.

Regards,

Robin Davies.