The future of MIDI Export

jeff

Something that 2.5 had that got lost in 3 was the concept of MIDI Export. What this did was send MIDI events out whenever a parameter was changed in the UI or a script in order to keep external MIDI control surfaces in visual sync with what the Mobius parameters actually were.

There were a few other uses for this, like sending an arbitrary MIDI message out at the end of the loop.

I was wondering if any of you used this in the past, or have ideas about how this should work now?
I've been putting it off because there didn't seem to be much demand for it. But I've got a few newer bi-directional MIDI controllers now and am seeing a use for it.

This is somewhat related to OSC which has also been on the back burner. Basically, what "events" that happen in the tracks and loops would you like to have exported over either MIDI or OSC?

edm11

jeff Basically, what "events" that happen in the tracks and loops would you like to have exported over either MIDI or OSC?

I think the shorter list would be, which events that happen in the tracks in loops wouldn't you like to have exported over MIDI or OSC? I can't think of any that wouldn't be useful in some context, especially when you consider that these events can be sent to outside apps, adding variables for use in the various scripting and event driven capabilities of those apps.

jeff

From my perspective it has to do with the amount of instrumentation that has to be put in place and the complexity of the UI that has to be built just in order to ask for everything that is possible. Some examples:

   the start and end of every major mode (Record, Multiply, Insert...)
    the start and end of every minor mode (Overdub, SpeedShift, RateShift, Reverse, TrackSyncMaster, MIDISyncMaster)
   the invocation of every function, both when they are requested and when they eventually happen due to quantization or loop switch stacking
   changes in function invocation time after scheduling due to loop extension during Multiply/Insert
   changes in the value of every parameter (muteMode, altFeedbackDisable, switchQuantize)
   changes in the value of every "internal variable" (loopLength, subcycleCount, syncDriftDealign)

There are literally hundreds of these, and even if I could instrument all of them, the UI to ask for them would be several times larger and more complex than the current binding UI. Oh, and for all of those multiply it by 8 (or if you're manymanyhaha 32) tracks.

I'm going to have to draw the line somewhere. In the past this was limited to changes to the major parameters, basically if you could bind a MIDI controller to it, you could export it. Then a few of the major loop events like reaching the start/end, reaching a cycle, and a few others. The entry and exit of modes seems useful.

edm11

jeff Oh, and for all of those multiply it by 8 (or if you're manymanyhaha 32) tracks.

I get it. In a previous incarnation I was scripting nearly everything for 10 tracks using 4 loops each . That's a lot of widgets in GP!

But hey, this is your Pandora'a Box and I understand the need to cap it off at some point.

bernhard

jeff Possibly don't implement a GUI for it, but rather offer a configuration text file (yaml, xml, ...).

jeff

lol, not sure why it did that block formatting on the examples, must be thinking it was Markdown

manymanyhaha

Apologies, trying to wrap my head around this. Haven't had a need for Feedback from Mobius yet but that doesn't mean I won't if I begin to understand why I need it 🙂

Would you have a couple examples you could share of why this might be useful? I guess maybe if a Midi CC was sent at the start of Record and then another at the end, you could toggle an effect in the host, something like that?

edm11

manymanyhaha Would you have a couple examples you could share of why this might be useful?

It has to do with syncing other things elsewhere based on the state of certain things in Mobius.
e.g. When something on Track A [starts, stops, changes], send a message somewhere else to [start, stop, change] something there..

It could be mix control, it could be lighting control, it could be transport start/stop on a file player.
Perhaps its just simple bi-directional feedback on controllers that support that kind of thing so you can control and visualize Mobius without the need to see the app/plugin window.

jeff

Hmm, a configuration text file would sure make things easier. And in practice, it's easier to manage a large number of exports as text than it is to click-till-your-sick in the UI trying to accomplish that. Less technical users may be afraid of that but if they've got control surfaces and dozens of exports to manage they're already pretty technical. I like this idea a lot.

Now that I think about it, that's kind of what I did for OSC in 2.5, I never did get around to a UI, you had to do everything in a big XML file. But we can do better than XML. Yaml is nice.

Leftyloopy

This is something that I definitely would benefit from cause we use two bcr2000 for controlling our 16 tracks' volume, pan, and feedback.
Over the years I was able to get this to work but because the behringer drivers left much to be desired, or mobius itself, can't tell which was the culprit, this functonality would dissapear. I even lost this on Moboius 2.5 plugging the bcr's through the 5 pin midi connection, which leaves the drivers out of the equation.
I recall you mentioning something on an ealier post that it would have to involve devices using separate midi channels to maje it work. And from the get go we had prgrammed all our midi controllers on separate channels.
So, hopefully is doable.
The main reason is that sometimes we would fade tracks out and then accidentally move a rotary on the behringer and the volume would jump like crazy because of the behringer not knowing that the channel had been faded out. Crossing my fingers is not a lot of work to have this functionalty back ;-)

jeff

I've been thinking....this is fitting well with something else I've been toying with
on the side: Event Scriptlets.

Something happens. A parameter changes, a loop reaches the end, a loop goes into Mute mode,
a track is reset. What do you want to do? Send a MIDI event, send an OSC message, trigger a sample, turn on the blue spot, run a script.

MIDI Export and OSC are really just two examples of side effects that can happen when the looping engine reaches a state. The engine needs to be designed in a way that user defined behavior can be inserted at various points, what programmers might call a callback, listener, or lambda. Or what audio people might think of as a patch point or plugin. The engine doesn't care what these do, it just needs to provide a way to do them.

So we have an engine all instrumented and ready to tell us when things happen, how do you tell it what you want to do? This is a massive GUI problem. But we don't necessarily need a GUI, we can invent a language. It isn't a Mobius script (though it COULD be...more on that later). Consider some exmaples:

when at loopEnd in track 2 midiout(1, 42)
when mode mute in track 1 send("/some/long/osc/message")
when function Record in track 1 {in not 1 Mute}

In that last example notice "{in not 1 Mute}". That is a scriptlet. I've been spending a lot of time recently redesignging the scripting language. It is equivalent to this in the old scripting language.

for 2-8
Mute
End

The differences are it is more like a traditional language and doesn't require line breaks, and most importantly, it doesn't have to be in a file. It's just a string of text, it can go anywhere. Currently, I'm working on having this in bindings. Instead of binding a MIDI note to the name of a script file, you just bind a MIDI note to a line of scriptlet text. But this also works well to define the behavior that happens as a side effect of an engine event. Event Scriptlets.

What's missing is a way to associate engine events with scriptlets, which is exactly the same problem as associating an engine event with a MIDI export.

So now we have two languages: one for Mobius scriptlets, and one for this event association. There are
some syntactical advantages to having them be different, but we might be able to merge those.

As a final note, I'm liking this "command file" concept for bindings as well as exports. Imagine this:

// this is a file that defines a bunch of MIDI bindings

// this is a fully specified binding
note 42 channel 1 track 3 Record

// this line defines default characteristics for the bindings
// that happen after it
with type note channel 1

// and now we just have a bunch of note numbers
42 Undo
43 Redo
44 NextLoop
45 PrevLoop

// and you can use symbolic names as well
C#4 NextTrack

You write a file that looks like that and Import it from the main menu. This automatically
generates the Binding Set in the mobius.xml and you can look at it in the UI as if you
had spent an hour wiggling the mouse.

jeff

If you've managed to hang in here this long, you might notice that a MIDI event is really
just another type of "engine event", it just happens from outside Mobius rather than inside.
Going back to this example

when function Record in track 1 {in not 1 Mute}

why not this?

when midiIn(1, 42) {in 1 Record; in not 1 Mute}

I don't think we would want to do this for all bindings. There are performance and ease-of-use
advantages for having them be simple associations that can be modeled and visualized easily.
But this does open the door for Programatic Bindings. I won't toss out a syntax for this yet
but imagine this:

when cc 1 to 8 use as outputLevel in 1 to 8

jeff

lol again, I don't know why Flarum is doing all that color coding in block comments. It's kind of festive, but distracting. I didn't intend to place any sort of emphasis on those words.

Leftyloopy

The fact that even though I use a plethora of scripts, mostly adapted but trial and error form the old forum and some that I still don’t why they work lol, I consider myself completely illiterate when it comes to lines, codes and stuff.
So, I might to brighten up to understand I depth what you wrote up there. Exciting, nonetheless!

jeff

The challenge for language design in applications like this is the tension between traditional scripting languages that make perfect sense to programmers, and non-programmers that aren't familiar with thinking that way. Most Mobius users are not programmers, so I'm trying to come up with something that flows more like natural speech, but is still consistent enough that it makes sense to programmers. Of course, not everyone is a native English speaker either so there are problems with that too. This is one of the reasons I'm not looking at Lua or Python, or any number of others that are very popular in the programming world, but are still difficult to understand for most people.

It's a hard problem and I may not succeed. But what I think I CAN do is make it much easier to share and adapt scripts that other people have written. Using a script should be as simple as downloading a file from a web site, dragging it onto the Mobius window, making a few selections in a GUI form, and you're done.

bernhard

I’d love these scriptlet capabilities!

gustebeast

Maybe it could start as a script only feature and then move to GUI later if that makes it easier. For recording states I was able to manually send MIDI messages with scripts like this

MidiOut control 4 3 127
Record
Wait last
MidiOut control 4 4 127

Probably would be cleaner to just listen for the start record and end record events and send MIDI that way, but this works just fine.

One thing I can't really do now that would be nice would be listening to loop start events for each loop. That way I could replicate the display shown in mobius where you can see each loop spinning independently. MIDI clock allows me to show the primary loop but not the other ones.

jonunderscore

gustebeast

+1, I also fudged something together using midi out from my scripts for each command, but would love to be able to see the loop "clocks" in my touchOSC interface and I am excited for the prospect of MIDI/OSC status export getting more fleshed out!

ericzang

+1 Being able to send loop engine states (rec, play, overdub, stopped, cleared, etc) would also be helpful for me in a setup with multiple controllers, and lemur performing conditional functions based on the loop states. No gui is ok. OSC is very welcome also. Thanks!