Midi mapping problem


#1

Hi,
I’m testing midi mapping in the A7 version of Oscistudio. Reading the documentation there are two possibilities: one by pressing the “m” key and selecting the slide and another by right clicking on the slide and entering the control number. The second option doesn’t work for me, maybe I’m entering it wrong.

Here you can see it midi mapping

Thanks.

Regards.

Javi


#2

I’m having this problem as well, except it only seems to be problematic for the CUE related buttons.


#3

hi!

@jandraka is it possible your control commands are coming in on another channel?

to use CC 5 on midi channel 1 you can type either 5 or 1.5
to use CC 7 on midi channel 2 you need to type 2.7

and so on.


#4

@kritzkratzi Oh wow, I didn’t know about this notation to designate different midi channels. Is there a way to select different types of encoders? For example: Relative 2s Complement, relative signed bit, relative binary offset, etc…


#5

oh, i didn’t know about these tbh :hushed:
in this sense the answer is definitely: nope, no support for that.

reading up on it a bit!


#6

Hi,
works for me if I use the “1.1” format. If I only enter the control number it does not work. I am on 13.4.1 M2 mac.

Regards.


#7

@kritzikratzi oh yes please! One cool implementation is if you have endless rotary encoders configured to increment upwards and downwards as opposed to “absolute mode” with a standard CC command.

I use an Akai MPD232 with Bitwig. If I leave the rotary encoders of the Akai set to their default type (CC) and map those encoders to things like my Channel faders or my effect sends, the behavior is typical absolute encoder control with 128 steps of resolution for that particular fader. This seems to be OsciStudio’s implementation as well.

This is all great and cool, but there is problem if playback is running with automation on a lane you want to send a CC signal to. Imagine a performance is running and automation has lowered the CC command to 1 while the rotary encoder’s absolute position is still at 127. If you try to change the fader up because automation has made it too ‘quiet’ by touching your rotary encoder, the value will first shoot to 127 when the encoder retakes control before you can bring it down to the modest value you wanted. It would be more desirable in most situations to not “spike” your CCs this way. A similar thing happens in OsciStudio when I want to control a scene with the “cues” feature but I still want to control those sliders manually.

The cue will move the slider drastically, but if try to change that same slider afterwards with the rotary encoder the slider will jump to the value of the rotary encoder’s absolute position rather than increment upwards or downwards predictably.

The solution I have found is to set your encoders to “INC/DEC2” on the Akai. Now if you turn the rotary encoder “up” it sends “01” for that CC# and channel. If I turn it down it sends “7f”.

In Bitwig, I can select “relative 2s Complement” (again, the default is “absolute”). NOW if automation is running during a performance and I want to tweak a value that automation has changed, touching the same endless rotary encoder will predictably increment or decrement that value in whatever step resolution the software decides.

Ardour supports this as well, but you have to use an editor on the xml file that holds the various MIDI maps (*.map).

This would be super powerful in OsciStudio. You could allow the timeline automation or cues to drive complex automation, but you could still interact with the automation in ways that did not create unpleasant CC “spikes” as I described.


#8

ok, this should be possible to implement … why not!

i don’t want to buy this controller right away. can you maybe

  • record midi
  • record a video from your phone

for each of the modes.

they don’t have to be perfectly in sync, if you try to press record at the same time it should be good enough.

not sure, but this midi recorder might work so that i can then play back the CC data:
http://www.midieditor.org/index.php?category=download


#9

Sorry this took so long! I really wanted to try that MidiEditor program, but got frustrated trying to get the qt dependecies sorted out, so I just sent a video. Check your DM’s


#10

don’t worry, i’m also not fast :slight_smile:


#11

to use CC 5 on midi channel 1 you can type either 5 or 1.5
to use CC 7 on midi channel 2 you need to type 2.7

A follow up question for this topic, can we assign midi notes in a similar way?

Previously in A6, I would map midi notes to CUE commands using the ‘m’ key method, but that stopped working in A7.


#12

hi!

ok, the “m” key should really work! is it possible that you have a stuck key. if you make sure caps lock is off, then switch to oscistudio and press of these keys once (just press and release): ctrl, shift, alt/option. if you press “m” then, does it work now?


Unable to get LaunchControl XL to work with OsciStudio
#13

I should clarify. The ‘m’ key works and I can enter midi mapping mode in A7 with the blue overlay. I can click different sliders and the yellow box starts flashing around the designated slider indicating that it’s ready to map, and I can also assign that slider by sending a CC midi command (all in A7 and A6).

What does *not work in A7, is using the midi mapping mode to assign commands to buttons in OsciStudio. In A6 I could click on “CUE” buttons and “Enable” buttons, just as I would click on sliders, and assign them to midi notes or midi switches on my controllers.

The breakdown specifically happens in the midi mapping mode, I cannot get the yellow flashing box to appear around the CUE buttons or Enable buttons. Instead of a yellow flashing box, clicking on them just toggles them as though the midi mode isn’t enabled.

I’ve attached a screen cap from A6.


#14

i see! thanks for clarifying.

i will take a look tomorrow.


#15

thank you again!

this is now fixed, and will be part of the next release.


#16

That is such good news! I’ve been manually editing my SAVE files in a text editor to get around this. Super excited for the new release.


#17

yea, sorry about that!