When I connect the Midi Fighter Twister the led ring around the rotary controller is not updated when the value is in the device is updated. This would be great when switching paddleboards or snapshots or even when changing the values in the WebUI.
+1 I would also love this using my twister! It is already a good companion for the Mod. I also think it would be a great addition to the looperlative plugin and would open for adding new dimensions to plugins and plugin development. It does give some cc value feedback when knobs are turned, but to be able utilize the built in sequencer for instance have gain monitoring in the mixers would be awesome!!
I fully agree! I want to buy one but without feedback I feel it is less useful.
This has been wished before; Two Way midi mapping If we summon some interest behind it, maybe it could manifest in the near future. The mod team often responds quickly when there is a real wish in the community. BTW There is also a guy coding a new open source firmware for the twister. Alternative firmware MidiFighterTwisterMaybe that could make things more interesting from even more perspectives?
The MIDI Fighter does this by receiving MIDI back over USB, no?
Can’t you somehow go around this by sending this data on the USB MIDI in of the MIDI Fighter that should appear on the WebGUI? Just wondering about a workaround for now.
there is a workaround as I mentioned in this post:
Yes a workaround is nice, but still the mod webUI is already a bit hard to navigate. I understand the idea behind it is to have it looking like a “real paddleboard” but it is fragmented an not fluent to use. Sorry!
On a computer screen you better have interfaces that are build for it. Check out the interface of eg. the kilohearts plugin. It is designed to work on the screen and not to look like it is something other…
Well, a streamlined editing should be important for the success of the devices.
Don’t take me (or even @spunktsch) wrong, the idea of the workaround is exactly that, a workaround. Not meant to be a solution to the problem. Using workarounds helps you get the issue solved while the feature is not implemented. On your particular example, I personally see the need for such a feature to be implemented. Yet, as that can’t happen overnight, going around with other solutions will help you get the desired result faster.
No need to be sorry It’s your feedback and that is more than welcome!
Yes, the idea is that it looks like a real pedalboard and we understand that it brings its pros and contras. Yet, these UI pros and contras get into an extremely subjective area that makes it way harder to brainstorm and find proposals for solutions that make everyone happy.
Grabbing on the example that you gave of kilohearts, I can see a lot of rotary encoders on the UI, which in my personal perspective doesn’t make it a super “screen targeted” interface for mouse/keyboard usage. There was a big talk about that in some other thread here in the forum and quickly we found the lack of a clear general consense. I also see representations of patching cables on kilohearts - just like on the MOD platform - what once again, makes me ask if it’s really developed with a screen perspective only in mind. As I said in that other thread, I feel that we humans need always some sort of familiarity to quickly and better understand the tools. If that make sense on the tool that we are using? Especially in software that is highly arguable. With this in mind, the software developers simply take different paths and decisions in order to deliver that familiarity and this makes it more familiar to ones and less to others, just like a guitar is more familiar to a guitar player than to a piano player.
Moreover, perhaps the most screen targeted interface for a computer is something like MS-DOS or the terminal window (which actually you can use to interact with MOD devices). But I guess we are all happy to not have that as the main UI for our computer softwares nowadays
Yes, I guesss this can get close to a philosophical discussion. Still a software like say Ableton is definetly more streamlined to be used with mouse and keybord to edit your ideas quickly. Creativity likes speed. For me it does not need to represent a real device, I prefer less graphic clutter. Sure the GUI of a module should be somewhat recogniseable, but liite variety is needed for that.
Pricisely where the WebUI of the MOD lacks for me is the cable thing, zooming of the canvas and to have two views for each device. In Ableton and in Kilohearts it is solved with predefined slots or tracks. No cables at all. Zooming is done by scrolling, also due to the slot/tracks. And I guess all device parameter should be in the device, no doubling of knobs. ( In MOD I have to remember two layouts for each device… )
Also the library of devices on the bottom is hard to navigate. ( mayba because of the left right scrolling, mayby better vertical on the side ).
Ah and of course a keybord shortcut system for basic functions. ( copy/paste devices. Open a settings state of the device… ).
Really this are just some ideas thrown in and i realise that some of these go in a very different direction
Indeed, that’s exactly what I was trying to say.
I agree, but still, you have the piano roll - a graphical representation of a piano keyboard - and representations of encoders and faders.
We are kind of getting out of topic here, so I think it is better to create a new thread for this discussion. That I feel that is indeed useful, needed, and helpful.
So, I strongly encourage you to compile this feedback and create a new thread about it
Just a comment on this one, a lot of trackpads nowadays (and not only) actually allow you horizontal scrolling.