should the MIDI input on TBC2 be working?
and is it using the A or B TRS MIDI standard?
also from what I’m seeing via the TBC2 panel the proc amp controls are only showing up when using SD inputs (hue,saturation,brightness,contrast) is that going to be extended to the other inputs at some point?
extending that thought the MIDI map specifies SD processor saturation so I’m assuming if the midi is working the only the crossfade will do anything if you are running anything other than SD rates.
it also looks like encoder a crossfade is mapped to CC0 which can be problematic for different controllers. For instance the 16n can’t send midi out via CC0.
I got MIDI working via the 16n using MIDI standard A
because 16n can not send out on CC0 and I’m running 1080i that means I can only control the encoder B crossfade. It is still so much easier though.
I hope we will be able to change the A&B sources via MIDI for both encoders at some point.
now I just need to figure out why the media loader hasn’t worked for me yet. I’m formatting from a Mac (12.3.1) with disk utility to FAT32 and loading images into folders. I didn’t put all those folders inside of a media folder.
“/media/folder/frame1.JPG” this line from the documentation leads me to believe that I should try that. I must have missed it the first couple times.
EDIT: Putting the subfolders for TBC2 media into a folder called media did the trick now all the images are loading!
however on TBC2 it seems like the MIDI control is not fully fading between the two sources
the setup in the video is 16n going into TBC2 and the crossfade on TBC2 is also selected. This problem persists even if the crossfade isn’t currently selected.
What I do in the video is fade with midi first and then you can see what is still showing up from the other video. Then I press the button on TBC2 to move the crossfade one time and then it looks right to me.
the 0 state of the initial camera feed looks like it should to me. I don’t see any of the media loader bird picture showing through
I just tried with the second input as a source instead of the media loader with the same behavior.
You can pretty clearly tell When controlled the crossfader with MIDI and it not being selected on the TBC2 that the slider itself doesn’t go all the way to 100%
I love that the crossfader on the TBC2 display shows where it is at when being controlled by MIDI!
Thanks! I’ve logged the MIDI scaling issue and a fix for that will be in the next firmware revision. We are working on 1.0.1 (bugfixes) and 1.1.0 (remaining features) for the past couple of weeks. How do you think we should handle assignable MIDI? Should we update the CC map to start at a different number or add a MIDI assignment page to the GUI? We could do a MIDI learn mode, I just worry about everything on the display being too cramped. Another option is storing MIDI map as easily editable JSON data on the SD card.
My preference would be a “MIDI assignment page to the GUI” followed by “start at a different number” because I dislike having to go back and forth un/mounting SD cards between the PC and the rack, it kills my vibe.
Hey there, I don’t have my TBC2 yet, but I would like to vote for a MIDI assignment page in the GUI. Crucially, we need to be able to assign specific MIDI CC’s to specific parameters, not just a contiguous block of CC’s.
MIDI assignment must be able to handle not just controller number, but MIDI channel as well. E.g. I have the world’s greatest antique MIDI controller, the JL Cooper CS-10^2. It only outputs on channel 16, with no option to change that. I am working around that by sending it through a MOTU MIDI Timepiece AV, which has advanced routing capabilities, including channel reassignment. But I am privileged to have that ability. Especially for artists doing mobile setups, total flexibility in TBC MIDI assignment is needed.
MIDI learn is a nice thing to have, but I wouldn’t put it on the list of high priorities.
Using CC 0 is perfectly legal, all of the CC purposes are suggestions rather than laws, but since CC 0-11 and 120-127 have behaviors that are a little bit more widely honored than the other suggestions, it seems more common for the default values of arbitrary controllers to be in the 12-119 range.
I think putting default assignments into the range CC 32-63 (as the 16n does) makes a lot of sense, in part because you can easily use those controllers in 14-bit mode!
I think a user defined transpose/offset of the starting CC# is probably the least intrusive way to handle it for now. I can add that as a setting next to MIDI channel in the system menu. The map will start at CC#0 + user defined offset. So with an offset of 32 you can have it match the 16n range.
I like the idea of a more robust MIDI router GUI with the ability to save mappings – this may end up being part of the MemPal Mk2 dev path, since we’ll be developing it using TBC2 and a MIDI controller.
Why doesn’t 16n support CC#0? That seems like a bug.
also from what I’m seeing via the TBC2 panel the proc amp controls are only showing up when using SD inputs (hue,saturation,brightness,contrast) is that going to be extended to the other inputs at some point?
That’s right, the proc amp controls only apply to the “SDP” section of the frontend (which applies to the CVBS + S-Video inputs) in 1.0. The “CP” proc-amp (Component and VGA) needs to be controlled differently.
dewb and I were talking about this on the discord and we got it sorted at least initially. 16n can absolutely use CC0 however the web editor up/down ticker was bounded to 1-127. I entered 0 directly into the number box rather than using the interface and it worked fine. Dewb submitted a PR on their GitHub for the issue.
hi there-
i have another question on a similar topic.
i use an iPad running Lemur (RIP) to send midi messages.
i have the memory palace set up properly, with the same settings as the tbc2 (both midi type a, same channel, same cc).
the memory palace works perfectly, but I can’t seem to get any midi message into the tbc2. am I doing something wrong?
Yes, but we are limited a bit by the scope of the 4-button GUI. The next step would be storing the midi configuration in a settings file on the SD card, so that it can be manipulated and backed up externally.
I guess, everything that’s modifiable?
My idea was to create an interface on an iPad and control parameters with it (TouchOSC). Simple stuff like changing inputs per channel and saving the current settings would be far quicker/easier with that than scrolling and selecting with the buttons, especially when patched. Could pretty much map the whole module to the iPad
