Hi all,
I am currently working on an alternative firmware for the Midifighter Twister called NEON_SAMURAI, github repo is available here.
Its still a WIP with no ETA on a release yet, but I know a few individuals on this forum have a Twister and I am looking for some feedback on the feature set, changes, improvements.
Happy for any comments/queries.
Cheers,
Nic
18 Likes
I have been meaning to roll a very basic MFT firmware for 14b Ccs, which is all I really want. Would be happy to contribute if you like.
4 Likes
Oooh, I like it! Wonderful work- In a recent AV show I used the acceleration and a Touchdesigner patch to keep track of where my controllers were and to make it more than the 127 values it has normally. Do I understand correctly that more resolution is one of the key things in this firmware?
2 Likes
thom
4
Great project.
I’d really like to be able to access each LED separately.
I was disappointed this wasn’t possible with the original firmware. It led me to sell the device shortly after buying it a few years ago, even though I liked the hardware.
I have since acquired another one for some specific jobs, but this possibility would allow me to use the Twister as I originally intended.
5 Likes
Would be a dream to just have the LEDs be decoupled so they can be controlled entirely through a Norns script, with the encoders just passing 14-bit CC. I imagine that’s sorta what an Arc is like but I’ll probably never know.
13 Likes
Oh - yes me too. I would be happy with something quite minimal: 14b Ccs, decoupled LEDs. Settable channel and cc number would be nice but not necessary. I have been meaning to code that up since a randomly acquired one of these things last year, but it hasn’t been hi prio.
This could maybe be separate project since scope is so small. (In my mind there are strong benefits to having fewer features.)
9 Likes
The firmware design is fairly decoupled so it would not be too difficult to provide external control of the LEDs.
I have no experience with norns/touch designer, what is the control mechanism? I assume midi sysex. Perhaps someone could link some documentation or provide some insight.
The current design of the firmware provides 3 banks of encoders, each encoder has two assignable parameters (which can operate individually via toggling, or simultaneously), so a total of 48 parameters:
- 16-bit internal values (the encoders themselves are not 16-bit, but this provides the possibility of handling 16-bit parameters using acceleration and interpolation).
- Configurable operating arcs - each parameter can operate within a defined region of the encoder rotation (overlapping of the parameters is also supported).
- Configurable value ranges - you can limit the number range of each parameter, for example with Midi CC you could limit the range from 10 to 100.
- Midi Follow - parameters will be updated with MIDI data received from the external device. I have tested this in Bitwig using the DrivenByMoss extension to configure each parameter to modify a device parameters - any changes in Bitwig are represented on the controller.
- Display Modes - still a work in progress but I have something that closely resembles the original firmware. I am working on a mode that displays both the parameters at the same time but its complicated…
- Midi - you can set any channel, any CC for each parameter (was always a bit confused why this was not in the original firmware).
FYI this is a clean implementation from the ground-up, the project is setup to use vs-code and is fairly easy to get up and running (if you are on linux).
May I ask that if you have a feature request you create a ticket in the Issues on Github so that I can keep track.
6 Likes
I have a MFT. I don’t code but would be happy to help out with testing and such, although I would need a bit of handholding to get started…
2 Likes
A preview of the 14-bit mode using an extension in Bitwig. It automatically detects 14-bit midi received from the controller:
6 Likes
