Ideas for improving the Midi workflow.

[ScreenDream]

This is intended as a basis for discussion for improvements to the Midi side of things as recently discussed on Discord:

At the moment (as of 16.9.2022) there is only one Midi Input operator, it only supports Midi learn to set it up and it only receives Midi CCs AFAICS.

I see quite some potential in this area so I want to lay out some possible directions here.

• Also support Midi Notes, Pitchbend and other controller types. Pitchbend is for instance used in all Mackie compatible controllers for the faders since it allows 14bit resolution. Notes would allow to directly react to Midi music. Other controllers like pressure would also allow to for instance support MPE expressive Midi.
• Midi output would allow to generate Notes or controller signals to steer external gear by events in the animation and user interaction.
• Some Midi specific operators could help with things like transposing of notes, generating Midi data etc.

On the technical side, this discussion brought up the current limitation to Midi learn as the only (?) way to select the intended input device. While this works well enough if there is only one or a limited number of controllers attached, in more busy environments, this is a serious limitation, since it may be hard to only have one single signal. For instance the Roli Seaboard Block sends Pressure, Timbre (CC 74), Note and Pitchbend more or less at the same time continuously...

Another issue with the current limitation is, that on Windows, many Midi controllers only allow one application to use the Midi port and throw a rather cryptic error about "Not enough Memory" if a second app tries to access it. Since tooll 3 listens to all controllers in the system, it also has to open all ports, which then leads to the situation that the app first started wins - not a good thing in a live setup.

Sense mentioned workarounds via LoopMidi and MidiOx, but I personally think those are problematic in a production environment, where there may be other constraints to the setup and t3 shouldn't require these.

The common practice in all audio applications I use is, to have some kind of preferences where one can select what Midi devices should be used. This has several advantages:

• Tool only listens to devices you actually want to use with it = less noise.
• It does not interfere with devices that are open in another application if each app has clearly defined it's inputs without overlap.
• No external tools are needed (although on Windows something like LoopMidi is indeed needed for inter-app-Midi communication.

Now there is an interesting issue with this, since every project in t3 can have it's own setup, one global preference isn't really cutting it.

So I came up with a couple of ideas for discussion what makes sense and is feasible in the context of t3:

• Instead of having a global setup, there could be an operator "Midi Setup" that allows you to set up which devices to use. It would be mandatory to use Midi and would define what devices are opened. It could also contain more setup options like what kind of data to listen to etc.
• This could then be connected to:
  • a.) Midi Input operators for Notes, CCs, Pitchbend, Pressure etc. - either as dedicated individual nodes or as a unified node with selectors for what to use.
  • b.) Midi Modifiers like transpose, channel selectors etc.
  • c.) Midi Outputs, which would have the same Midi devices available as the Midi Setup operator or it's own selection.

All these would allow Midi learn as well as selecting devices, CCs etc. manually.

A complicated topic with Midi is, that for instance with Notes you do not want one node for every individual Note you want to react to or create, that would make working with a melody rather tedious. So you need something like a list, where you can get at all notes and their current state and velocity at once. This needs some good planning in the context of t3 to make it as easy to use as possible.

So there you have it. Became a bit more involved than the initial "can we have a Midi output too"... ;-)

Looking forward to learn how this can be implemented!

Cheers,

Tom

[pixtur]

Also support Midi Notes

Midi-Notes are already supported. But it's kind of hidden and probably needs a better / clearer user interface.

... in more busy environments, this is a serious limitation, since it may be hard to only have one single signal. For instance the Roli Seaboard Block sends Pressure, Timbre (CC 74), Note and Pitchbend more or less at the same time continuously...

Agreed. We have the same problem with [OscInput]

Some thoughts on that:

• Setup-Operators are kind of difficult in T3 because they would be required to be evaluated (I.e. at the very right of the currently rendered graph). There are a bunch of these already (like my personal [VJSetup]) but it's confusing and cumbersome to work with these. (A side note, because you might be tempted to suggest it next: non-evaluated or non-connected operators should not have any effect. That's one of the core principles of Tooll).
• The Soundtrack setting actually already works like a project specific setup. It would probably make sense to restructure the timeline settings into a new project settings view to group such. This would not only clarify the use-interface. it would also provide a foundation to several other project specific settings.
• The currently implementation of MidiProviders is a low level Tooll-wide API that is also used for things like Beat-Tapping and activating and blending of SnapShots. To refactor this implementation into one that dynamically (un)registers MidiDevices while you jump in and out of projects will be a lot of work and might have side effects that requires extensive testing and probably some breaks in backwards compatibility.

[ScreenDream]

Interesting - thank you for the feedback and thoughts!

Yeah, I think even the most modular environments I've used (Usine Hollyhock etc.) always had a static Midi/Audio base setup, so it may boil down to that, if a more modular setup is too complicated.

This may actually make the most sense in the end, since usually you have one set of audio interface(s) and one set of midi controllers on a given machine and especially midi devices normally aren't exchangeable for others 1:1 anyway. I personally would be fine with one global setup for audio and midi - that also would give you one central place to set up your gear instead of having to re-do it for each project.

From there on the modular concept should hold though, although the concept of no out-of-chain modules will make it less visibly obvious than a structure where you have several outputs for graphics, midi and audio. But maybe this could be solved with something like a multi-input node with separate inputs for these kinds of protocol layers (Audio, Midi, OSC, DMX...)? Would that make sense? Or at least the artist could use an execute node to simulate separate ports and in such a way have the visual representation of separate lines for the protocols.

As for the notes: Searching for "Midi" brought up only one node and that seemed to support only CCs - I'm all ears if there are more options ;-)

Cheers,

Tom

[marcus-universe]

Is there a way to use the midi clock for actions? 😅