I am trying to figure out use cases where 8FACE MK2 would be preferred over TRANSIT.
The big difference between the two is TRANSIT can morph between presets, while 8FACE MK2 preset transitions are always instantaneous. Associated with that difference, TRANSIT has the amazing Phase selection option that provides a continuous CV controlled morph between all defined presets…
But TRANSIT can also do instantaneous transitions with the Fade slider set to zero. So what is it that 8FACE MK2 offers that TRANSIT doesn’t?
Other TRANSIT advantages:
Option to map individual parameters in addition to whole modules (module mapping still maps individual parameters en masse)
Ability to unmap parameters using both the target parameter context menu and the TRANSIT menu. As far as I can tell, 8FACE only allows unmapping from the 8FACE menu.
TRANSIT offers more preset slots (12 up to 96 as opposed to 8 up to 64)
I only see one difference that may favor 8FACE MK2 - The method by which mappings are displayed. TRANSIT marks each mapped parameter with a small square that may be difficult to see, and multiple TRANSIT modules all use the same color. 8FACE MK2 draws a colored box around the entire mapped module, which is easier to see, and each 8FACE MK2 can use a different color.
I suppose 3hp vs 5hp might be an ever so slight advantage for 8FACE, but that is splitting hairs.
Am I missing a significant use case that favors 8FACE MK2?
Is there a significant CPU utilization difference between the two?
I also wondered why there are 2 versions of 8face. The standard version offers the option of mapping modules on the right-hand side. With mk2, you can only map modules on the left side or modules that you have selected. If I had to guess, I would say that 8face is less cpu intensive than 8face mk2 or Transit, because it has fewer features. To be honest, I use Transit less often because it takes up a few pixels more space than 8face and from that I pick whichever one I click on first^^. I guess the reason why 8Face and 8Face MK2 are still in the library is so that patches where these modules were included in the past still work today. But I would also be interested in the real reason why there are 3 modules
I see why 8FACE remains relevant. Its major limitation is it can only map a single module, and it must remain adjacent to that module. Move the 8FACE and it breaks the control. But with that limitation also comes an advantage - the snapshots may be applied to any instance of the same module type. Move the 8FACE next to a different instance of the same module, and it instantly gets control with the same snapshots. I think that can even carry forward to multiple patches if you save snapshots as presets? I can see how that could be very useful.
But 8FACE MK2 - I still see very little that it offers over TRANSIT
I don’t prefer one to the other per se, but i can say 8FACE is critical to several projects I’m working on and I’m sweating bullets waiting for it to come to v.2
I won’t elaborate much as most is already written in the manuals of the modules:
TRANSIT is a parameter morpher, it interpolates the values of an arbitrary selection of parameters of any module in your patch.
8FACE is a preset switcher. It saves and loads up to 8 presets of any module, including every setting, even context menu options, random states, loaded files and so on, anything the bound module stores in its preset.
8FACE mk2 is a next-level update of 8FACE, it allows more than 8 snapshots with its expanders and simultaneously controlling multiple modules in your patch without the need of placing 8FACE mk2 next to them.
Ahhh - that is the missing link for me - context menu settings etc! That is a major advantage of any flavor of 8FACE over TRANSIT. The latter strictly works with parameters. It wasn’t obvious to me from the manual that 8FACE did that. I knew 8FACE and TRANSIT were fundamentally different in the mechanism by which they operate, but now I better understand the implications for both.
Thanks Ben. And have fun with your hardware endeavors!
Yes, I got it working, my modules. It was in relation to the placement of the 7segment display. I’t s a bit weird cause it worked perfectly in V1, when I put it in res/Display folder. Now it seems to only work when directly in res folder.
I can build the code, no issues and then when I put the release in the folder it will crash VCV. But I can just move the display thing to the right folder, even after build abd it will work. It’s working, which is the most important.
Ahh Yes I found the Stoermelder build on their Github. Nice, thanks!
Only two set of modules left on the “have to have list”, RCM(for proper start/stop/reset control) and Lomas(the awesome sampler).
