Open Stage Control (Tutorial) - An alternative to Lemur and TouchOSC

[Manaberry]

The ideal articulation widget.. hmm...

- An array of buttons, dynamically displayed based on MIDI received from DAW.
Personally I use up to 60 buttons per instrument.
- Labels for these buttons are also dynamically displayed, and contain articulation names, which are different for each instrument.
- A clever method of storing the names. Something that's fast to create and edit (not 60 individual text fields, maybe a string with separators instead?)
- Subcategories? To divide the articulation button array into short / long for example? Subcategory labels should respond dynamically.
- Individual colour options per button, also dynamically changed.
- MIDI output on button pressed. Note On, Program Change and CC to cover all cases.

That's about it

Thanks for your input! I'm gonna try to create a visual concept later this month.

@Grizzlymv Sadly yes, we do have limits because of the DAW :<

@vewilya Hey! I have no idea how Logic works. If there is anything like the "Generic remote" editor of Cubase, you should be able to use OSC easily as soon as your Mac and your daw receive the midi signal from the network.

 

[vewilya]

Thanks for your input! I'm gonna try to create a visual concept later this month.

@Grizzlymv Sadly yes, we do have limits because of the DAW :<

@vewilya Hey! I have no idea how Logic works. If there is anything like the "Generic remote" editor of Cubase, you should be able to use OSC easily as soon as your Mac and your daw receive the midi signal from the network.

Alright. Thx. I’ll do some research...

 

[Luke Davoll]

Hey everyone,

I have an idea for a widget. I've looked around in the documentation, but if it's there, I couldn't find it. Perhaps @Manaberry you could have a word with the creator if you guys think it'd be a good idea. My idea is this (hope this comes across in text ok)

We probably don't need to display every quantise/grid division on our touch screens. Or every marker. Or countless other things. I've seen the dropdown widget, and the modal window, but there's too much tapping/clicking. However, imagine a button that when held down brings up a grid of hidden buttons to the left and/or right or above or below with these grid values for example...but ONLY while the button is held down. Then you drag your finger over to the value, release and then the message is sent. Could be a great way of saving screen real estate. Think of it like an expanding button. I've seen something similar on lemur templates. What are your thoughts?

 

[Manaberry]

Hey everyone,

I have an idea for a widget. I've looked around in the documentation, but if it's there, I couldn't find it. Perhaps @Manaberry you could have a word with the creator if you guys think it'd be a good idea. My idea is this (hope this comes across in text ok)

We probably don't need to display every quantise/grid division on our touch screens. Or every marker. Or countless other things. I've seen the dropdown widget, and the modal window, but there's too much tapping/clicking. However, imagine a button that when held down brings up a grid of hidden buttons to the left and/or right or above or below with these grid values for example...but ONLY while the button is held down. Then you drag your finger over to the value, release and then the message is sent. Could be a great way of saving screen real estate. Think of it like an expanding button. I've seen something similar on lemur templates. What are your thoughts?

You refer to a commo rose system. Very smart indeed, I love that idea. I created a feature ticket, maybe the dev will enjoy this idea too!

 

[Grizzlymv]

Hey everyone,

I have an idea for a widget. I've looked around in the documentation, but if it's there, I couldn't find it. Perhaps @Manaberry you could have a word with the creator if you guys think it'd be a good idea. My idea is this (hope this comes across in text ok)

We probably don't need to display every quantise/grid division on our touch screens. Or every marker. Or countless other things. I've seen the dropdown widget, and the modal window, but there's too much tapping/clicking. However, imagine a button that when held down brings up a grid of hidden buttons to the left and/or right or above or below with these grid values for example...but ONLY while the button is held down. Then you drag your finger over to the value, release and then the message is sent. Could be a great way of saving screen real estate. Think of it like an expanding button. I've seen something similar on lemur templates. What are your thoughts?

Nice idea. Although, the modal window should be able to give you an almost equivalent today. That's what I did on my template. I mean, you can place it to appear just below,beside or above a button on screen. Personally, I trust more the behavior of 2 taps on 2 buttons rather than sliding over a few button and hoping none will be activated by accident.

One cool thing I'd like to see though, is to have multiple actions with dropdown. So, each items in the dropdown would have it's own OSC section, so for instance, using the example above, instead of modal window, a simple drowpdown could be used and each entry would send its own info to the DAW.

 

[Luke Davoll]

You refer to a commo rose system. Very smart indeed, I love that idea. I created a feature ticket, maybe the dev will enjoy this idea too!

Awesome, the developer is up for it. I read through your ticket, I'm not sure about the circular idea, but we'll see what he comes up with. My idea was more or less like this (2 minute mark) :


Hope I'm allowed to post that here. In no way am I suggesting ripping off Michael's intellectual property. Just wondering if that functionality is possible in osc.

Also, I read through the comments on github re: articulation switching. Would it be possible to draft together a custom script and see how that would work? I have really very little experience with scripting/coding but I love diving in and learning!

Peace.

 

[Grizzlymv]

Awesome, the developer is up for it. I read through your ticket, I'm not sure about the circular idea, but we'll see what he comes up with. My idea was more or less like this (2 minute mark) :


Hope I'm allowed to post that here. In no way am I suggesting ripping off Michael's intellectual property. Just wondering if that functionality is possible in osc.

Also, I read through the comments on github re: articulation switching. Would it be possible to draft together a custom script and see how that would work? I have really very little experience with scripting/coding but I love diving in and learning!

Peace.

seeing it in action make a lot more sense. I do like it. My concerns are still there though, as to ensure the touch screen won't lose the touch while sliding and therefore select the wrong thing. But otherwise, quick as shown the in the video, it's indeed more functional than the drop-down or modal. Hopefully though, each item could have it's own set of OSC value. But I second that idea!

 

[Grizzlymv]

Hey guys, wierd one. Anybody experienced similar behavior? I have my template setup in O.S.C. Which talks to a Generic Remote in Cubase, all on the same machine using loopMidi as per the tutorial on the 1st page. Now, if the Midi Input and Midi Output are set to my device set in LoopMIDI, I get a bunch of random midi data send to Cubase every move I do. Ie, If I switch track, the volume will change, the panning will change, etc. Funny fact, if I keep only the midi Input in the Generic Control and set Midi Output to None, works fine. Then if I do the inverse, in Generic Remote, keep only the MIDI output to my LoopMIDI device, and set the MIDI Input to none, it also works fine.

I'm trying to isolate which command is causing the issue, but it's not easy given the amount I've configured. Setting up a default Generic Remote set to both my LoopMIDI device in Input and Output works fine too. So it's definitely something in my Generic Remote, but I was just wondering if anybody noticed similar behavior on their side before I start destroying my config too much!

 

[Luke Davoll]

Hey guys, wierd one. Anybody experienced similar behavior? I have my template setup in O.S.C. Which talks to a Generic Remote in Cubase, all on the same machine using loopMidi as per the tutorial on the 1st page. Now, if the Midi Input and Midi Output are set to my device set in LoopMIDI, I get a bunch of random midi data send to Cubase every move I do. Ie, If I switch track, the volume will change, the panning will change, etc. Funny fact, if I keep only the midi Input in the Generic Control and set Midi Output to None, works fine. Then if I do the inverse, in Generic Remote, keep only the MIDI output to my LoopMIDI device, and set the MIDI Input to none, it also works fine.

I'm trying to isolate which command is causing the issue, but it's not easy given the amount I've configured. Setting up a default Generic Remote set to both my LoopMIDI device in Input and Output works fine too. So it's definitely something in my Generic Remote, but I was just wondering if anybody noticed similar behavior on their side before I start destroying my config too much!

Hey mate. When I first loaded Manaberry's template in to have a look and see what was going on, I got very odd behaviour (tracks not arming properly, a lot of strangeness). So you're not alone! But as I'm only interested in articulations at the moment, I just got rid of all the other stuff in the generic remote and filed it away for after when I finally sort these articulations out first. But something in there was messed up for sure.

On another note, are you a programmer by any chance? I need a bit of help. Maybe @Manaberry could take a quick look too if he has time. Anyway, I want to load in a custom script which makes creating articulations and showing buttons way easier. Take a look here:

https://github.com/jean-emmanuel/open-stage-control/issues/461#issuecomment-459716548

As cubase doesn't send track names over OSC, we have to do it using an input widget like has already been discussed. But I don't know how to modify the script. Any ideas?

 

[Grizzlymv]

Glad to see I'm not the only one with issue. I guess I'll start doing it from scratch and try to isolate which command is causing the issue.

As for the script, what do you need help with? Have you tried with the script yet? I'll have to check with O.S.C. how we should load custom script as I haven't tried that yet.

 

[Grizzlymv]

ok, so, so far I've noticed that if you use a Fader (ie, the selected track volume) in O.S.C., whether it is set to VST Mixer or Mixer / Selected / Volume in the Generic Remote, there's no wierd behavior in Cubase if you only use Transmit flag, but the second you add a Receive flag as well, then the volume will randomly decrease every time you come back to the track. So set 2 instrument tracks, set a fader in O.S.C. then in Cubase Generic Remote, configure one to Receive and Transmit as the flags in the upper window, and Mixer / Selected / Volume (or VST Mixer) and switch back and forth between the 2 tracks and you'll see what I mean.

So it's broken as soon as I say to Cubase to receive signal from O.S.C. Now I'm not sure if it's O.S.C. who is sending crap to Cubase, or if it's the VST Mixer / Selected / Volume which create noise when it's told to listen. I no longer have my TouchOSC device to compare. Can anyone confirm if it's a Cubase or O.S.C. issue? Haven't tested all other controls yet, but the Fader is definitely an issue with the track volume at the moment. I also tried from a new Fader, just to ensure nothing from @Manaberry template would interfere, but same result. And I can't set it to 0. If I try 0, it force it to 0.03, which is odd.

 

[Grizzlymv]

Alright, so everything works now, beside the Fader and Knob. So apparently, I can't find a way to have the fader (map to selected track volume) and the Knob (map to selected track panning) properly interact with Cubase. As soon as it is binded, then a bunch of random values start being added as soon as the track is selected. I'll have to reinstall TouchOSC and compare (if TouchOSC can accomodate such feature, I don't remember) to see if it's Cubase related, or O.S.C. related. Unless someone else can test it out?

Easy to reproduce:
- Add a Fader to O.S.C.
- MAx Value to 127. Min to 0
- Address: /Control
- Preargs (whaveter you set in Generic Remote. ex:
[
4,
2
]
- Address to your port. ex: midi:toPCStudio

Then in Cubase:
- create a Generic Remote
- set MIDI Input to your midi port (ex: toPCStudio)
- set MIDI Output to your midi port (ex: toPCStudio)
- Add a control and name it Volume
- Set the midi channel and address to what you specified in the preargs above (ex, 4 / 2)
- set Max value to 127 (should be by default)
- Set flags to Receive and Transmit (R,T)
- in the bottom pane, set the device to VST Mixer (or Mixer)
- set the channel to Selected
- set the Value/Action to Volume All

Then create 2 instruments tracks
And then alternate a few time between the 2 tracks, and you'll notice that the MIDI volume will start to randomly decrease instead of staying to 0 (or whatever default value you have on your track).

At least, all the other functions works for now, so it's not a so big deal to have to manually set the panning and volume with the mouse in Cubase. But would be nice to have it working properly. Maybe I did something wrong somewhere...

 

[Manaberry]

Sorry I'm very busy for now. I will try to help you guys once I'm more available to.
@Grizzlymv did you report this to Jean-Emmanuel? Maybe it's a software bug. It should not decrease like that. What's the precision value on your OSC fader widget? Try 0 instead of 1 or 2.

 

[Grizzlymv]

Sorry I'm very busy for now. I will try to help you guys once I'm more available to.
@Grizzlymv did you report this to Jean-Emmanuel? Maybe it's a software bug. It should not decrease like that. What's the precision value on your OSC fader widget? Try 0 instead of 1 or 2.

It is set to 0. It does the same even at 2. So it's not related to that. I'll submit the bug to Jean-Emmanuel.

 

[Grizzlymv]

actually I think I found the problem. In O.S.C. , you need to have /control as the address to have interraction with the DAW otherwise it doesn't work. But if you do, the second parameter of the preArgs seems to be sent to the DAW as a regular CC.

So, to easily reproduce it. First of all, go in the Generic Remote and disconnect both In and Out to ensure there's no interference. Then create a toggle button in O.S.C. set the address to /control, preArgs to [8,1] (or 9,1, 6,1 etc, as long as the second is 1 for this example), and the target needs to match your midiport, so midi:tomyport. The On value should be set to 127. The Off to 60.

Then add an instrument track in Cubase. Load Kontakt with a patch, make sure to show the keyboard in the Kontakt instance.

Then tap on the button, you'll see the modwheel going to the top. Then tap again, it will go to the middle. Now if you change the second argument of the pre-args from 1 to 7 and do it again, you'll see that it's the volume that gets affected.

I submitted it as a bug to Jean-Emmanuel, but I suspect this is the reason of our strange behavior. As soon as we use a common midi CC value as the second argument (1-modwheel, 2-breath, 7-volume, 10-pan, 11-expression, 64-sustain, etc) and we activate a button which have one of those set as the second parameter in the pre-args (7,1 or 9,7 or 3,11 etc) you'll end up with wierd problems.

Hope this brings some clarifications. So the workaround for now would be to use non standard CC value for the second argument, so you won't interfere.

 

[Grizzlymv]

alright. so for those interested, I opened a case with Jean-Emmanuel. What I discover is that no matter what MIDI channel is specified, the DAW (in this case, Cubase) will receive the signal no matter what MIDI channel you specified on your track. For instance, if you set an instrument track to Kontakt, set it to MIDI channel 1. Then in your Generic Remote, you set a function to record when Controller is set to Channel 9, address 7, and in OSC you a button that have /control as the address, [9,7] as the preargs, as soon as you'll hit the button in OSC, Cubase will record the Midi CC7 value despite not being on the same channel (track at 1, button at 9). This seems like a bug to me. We'll see what Jean-Emmanuel answer.

In the meantime, I remapped my Generic Remote to use the unmapped Midi CC according to this http://nickfever.com/music/midi-cc-list, so the good news is that there's no more interference with the DAW. The bad news is that I get a lot of garbage CC info on my track which I have to clean after each recording.

This did not happen with TouchOSC, so it's really an O.S.C. issue. Will report back when I have more to share.

 

[Luke Davoll]

alright. so for those interested, I opened a case with Jean-Emmanuel. What I discover is that no matter what MIDI channel is specified, the DAW (in this case, Cubase) will receive the signal no matter what MIDI channel you specified on your track. For instance, if you set an instrument track to Kontakt, set it to MIDI channel 1. Then in your Generic Remote, you set a function to record when Controller is set to Channel 9, address 7, and in OSC you a button that have /control as the address, [9,7] as the preargs, as soon as you'll hit the button in OSC, Cubase will record the Midi CC7 value despite not being on the same channel (track at 1, button at 9). This seems like a bug to me. We'll see what Jean-Emmanuel answer.

In the meantime, I remapped my Generic Remote to use the unmapped Midi CC according to this http://nickfever.com/music/midi-cc-list, so the good news is that there's no more interference with the DAW. The bad news is that I get a lot of garbage CC info on my track which I have to clean after each recording.

This did not happen with TouchOSC, so it's really an O.S.C. issue. Will report back when I have more to share.

For some reason, I didn't get an alert for these new messages :(
Very interesting what you've discovered. I'll try to reproduce the issue and let you know that at least I can reproduce it too.

 

[Grizzlymv]

Well, I'd be interrested to hear about your findings. Further discussions with Jean-Emmanuel ended up with a conclusion that O.S.C. does what it is expected, but Cubase is apparently the one having issues dealing with multiple CC sent over different midi channels. Here's an example: https://www.steinberg.net/forums/viewtopic.php?t=78411

Not sure yet what will be the best approach. My instrument tracks uses midi channel 1, so I could only listen to channel 1 for those and exclude all others. But I also have a bunch of MIDI tracks that work with VEP, and those uses between channels 1 and 16, so obviously would conflict. I did try to switch into Program Changes, but it didn't work for me (wasn't able to get the action triggered in Cubase). Unless someone have a better idea?

 

[Luke Davoll]

Well, I'd be interrested to hear about your findings. Further discussions with Jean-Emmanuel ended up with a conclusion that O.S.C. does what it is expected, but Cubase is apparently the one having issues dealing with multiple CC sent over different midi channels. Here's an example: https://www.steinberg.net/forums/viewtopic.php?t=78411

Not sure yet what will be the best approach. My instrument tracks uses midi channel 1, so I could only listen to channel 1 for those and exclude all others. But I also have a bunch of MIDI tracks that work with VEP, and those uses between channels 1 and 16, so obviously would conflict. I did try to switch into Program Changes, but it didn't work for me (wasn't able to get the action triggered in Cubase). Unless someone have a better idea?

I couldn't get program changes working either. Using a midi monitor insert, I was able to see that program change messages were sent from o-s-c, but I never got it actually changing articulations etc. It didn't work with expressions maps at all...

 

[Grizzlymv]

I couldn't get program changes working either. Using a midi monitor insert, I was able to see that program change messages were sent from o-s-c, but I never got it actually changing articulations etc. It didn't work with expressions maps at all...

The only other thing I could think of, is to filter out every CC value above 102. Following my tests over the weekend, now I'm only using 102-127 from midi channel 1-16 which aren't supposed to be used by anything. Otherwise I'm not too sure.