Hey gang, another tips and stuff video on the channel, this time, it's all about the Westilcht Perf │ Former.

Hi, alternative MEBITEK Firmware

Vinx PER|FORMER firmware – update v0.4.2 – April 23, 2026
https://vinxscorza.github.io/performer/
https://github.com/VinxScorza/performer/
Performance-focused and exploratory.

A DEMO / WALKTHROUGH VIDEO is now available at the following link:

What I’ve done in this version
• Aligned the Variation semantics, which now behave as a per-step keep/replace control against the original material in both Generators
• Reworked Generators footer/context layouts for a more uniform workflow across all Generators
• In Chaos, clamped Note and Note Range generation to a -24..+24 semitone window
• Made all Generators enter on the original version: the first generated Sequence now requires an explicit reroll action
• In 16-step Editing Mode, updated playhead feedback with dedicated state
• Fixed Voltage Mode behavior on Arp and Stochastic tracks (to be tested)

Also, in earlier versions
• Full evolution of the Generators ecosystem
(Random, Euclidean, Acid, Chaos: Vandalize / Wreck / Entropy)
→ now more coherent, with unified preview/apply safety and a shared playable workflow across the machine and Launchpad
• Added an experimental 16-step Edit Mode on Note Tracks (tested on LCXL, to be tested on BSP)
→ step editing via external controllers with 16 knobs + 16 pads
→ knobs = Note for the visible 16 steps
→ pads = Gate on/off
→ navigation across longer sequences in 16-step sections
• Improved Launchpad integration, with Generators Mode, Inits, and Undo/Redo
• Unified preview/apply workflow with safer destructive operations (1-level Undo/Redo)
• Unified Init behavior (Layer / Steps / Seq), selection-aware with consistent fallback logic
• Refinements in step selection (shift behavior, selection-or-all logic)
• Improvements in timing, clock/reset handling, and edge-safe sync
• Curve track extended with Gate Offset and Gate Length
• Improved handling of scales and operational limits
• Reduced memory footprint and improved runtime efficiency
• Simulators aligned with actual firmware behavior
• Expanded documentation, with a new manual featuring improved search + full Launchpad cheatsheet
• Overall ecosystem cleanup (site, docs, simulator, references)
And many other small improvements that add up, including a near-complete refactor of the Launchpad code

Full feature list
https://vinxscorza.github.io/performer/features/

The goal is to make the PER|FORMER more playable in a live context, while keeping it open to less predictable workflows.
A solid machine for performance, but also a crazy one for experimentation.

I’m kinda losing my mind over this fork.
If you find it useful, consider donating
https://vinxscorza.github.io/performer/donate/
If you notice any bugs or weird behavior, feel free to report it via GitHub, email, here, or wherever you like.
This fork has been moving fast — and since it’s just me, feedback really helps.

EDITED May 2nd, 12:51

Hello, I would like to know if it is possible to modulate the number of the pattern in playback with the CV of a track. For example on each step have a pattern number and read the steps randomly. I guess yes by reading the manual, but someone has already tested it or could test it for me? Thanks in advance.
ps: I don't have a performer yet, but I'm seriously considering equipping myself with one

EDITED Oct 13th, 08:25

Hello, I would like to know if it is possible to modulate the number of the pattern in playback with the CV of a track. For example on each step have a pattern number and read the steps randomly. I guess yes by reading the manual, but someone has already tested it or could test it for me? Thanks in advance.
ps: I don't have a performer yet, but I'm seriously considering equipping myself with one
-- mycose

Hello,
speaking for my firmware: yes, this should be possible.
You can use a track's internal CV output as a routing source and route it to the Pattern parameter of another track. So one track could generate stepped/random CV values, and those values could select patterns on another track.
I haven't tested this exact patch recently, so I don't want to overpromise the details, but conceptually this is supported. You may need to adjust Min/Max and the CV range to get clean pattern selection...

Thank you very much for your reply and for your work on the firmware. In fact, this is the version I am planning to use.

I would like to know if you have any information regarding the behavior of pattern modulation via CV. If the track controlling the patterns is on a clock division of 16, will the pattern change correctly at the start of each new pattern? Also, is the pattern switching instantaneous when triggered via CV?

Thank you very much for your reply and for your work on the firmware. In fact, this is the version I am planning to use.

I would like to know if you have any information regarding the behavior of pattern modulation via CV. If the track controlling the patterns is on a clock division of 16, will the pattern change correctly at the start of each new pattern? Also, is the pattern switching instantaneous when triggered via CV?
-- mycose

Well, I don't think this behaves like a queued pattern change that always waits for the next pattern start. From what I understand, the pattern changes when the CV value changes and the routing is processed. So if your control track changes value every 16 steps, the pattern should change around that moment, but I wouldn't want to promise perfect "change exactly at the next pattern boundary" behavior. At the moment I don't have time to test this specific setup, so I'd treat it as supported in principle, but not guaranteed as a tight synced pattern-switching feature. I'd suggest moving this discussion to the Modwiggler forum, where maybe you can find other people interested in this specific behavior and ready to test it:
https://www.modwiggler.com/forum/viewtopic.php?p=4507886#p4507886
;)