M-Vave Wireless MIDI Controller

Gavinski

@jamietopol said:

@Gavinski said:

@jamietopol said:

@Gavinski said:

@espiegel123 said:

@Gavinski said:

@Gavinski said:

@Gavinski said:

@espiegel123 said:
@Gavinski : in case it isn’t clear from win’s comment, jump and pickup modes are host responses to absolute mode.

Does the unit come configured sending relative or absolute values?

@espiegel123 said:
@Gavinski : in case it isn’t clear from win’s comment, jump and pickup modes are host responses to absolute mode.

Does the unit come configured sending relative or absolute values?

Using a midi monitor shows that it is sending fixed values, not incremental - if that is the way to check. I have no past experience checking for this. But yes, I think we have had this conversation before, actually, and very few iOS plugins handle pick up mode, is that right? In that case, I can’t really make use of this controller in the way I was hoping.

Also, btw, anyone know what the little knob icon (if that is what it is) shown on bottom right of this screenshot of AUM midi control does? By default is is off, greyed out, here it is on so it is lit up in green, but I have no clue what it does.

That icon makes the parameter the one controlled by the knob next to the node in the main view.

Ah yeah, ok! Useful, thanks.

@wim said:

@Gavinski said:
Using a midi monitor shows that it is sending fixed values, not incremental - if that is the way to check. I have no past experience checking for this.

What are the values it’s sending? An encoder generally sends a fixed value when turned clockwise and a different fixed value when turned counter-clockwise. Sometimes they send a higher or lower number if turned faster.

In absolute mode they act like a pot, sending 0-127.

Wim, what it is doing is this: twist left and it starts from whichever value 0-127 it was left at, 54, for example, then moves down to zero as you continue twisting left. As you twist right, it starts at whatever value it was left at, and then moves up to 127. If I move the slider inside the AUv3 I am controlling, if I then switch back to using the midi controller, it doesn’t pick up from where I left the slider in the plugin, it always picks up from whichever value, 0-127, it was last at the last time I moved the controller knob.

I have the same behavior and do not think it is possible for this controller to do what you want. I think we need the knob to send CC 96 every time a knob is turned clockwise and CC 97 every time a knob is turned counter-clockwise.

Ah, damn, so in this case the whole encoder knobs feature is basically irrelevant? Do you have the desktop app for configuring this Jamie? No option to set it to relative?

I do have the desktop software installed on a Windows laptop and I do not see any incremental options compared to CubeSuite on my iPad (other than the ability to store/recall multiple configurations).

Thanks for reporting back. It might be a good idea actually to mention this in the initial post, as I can imagine a fair few ppl are buying these for the endless encoders, but without a relative mode, as Wim said, they have no advantage over pots, and perhaps even a disadvantage compared to pots. Lovely little controller, but...

Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

Dante777

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Gavinski

@Dante777 said:

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Is there any midi tool that can be used to make this behave the way I want in AUM, do you know?

wim

@jamietopol said:
I do have the desktop software installed on a Windows laptop and I do not see any incremental options compared to CubeSuite on my iPad (other than the ability to store/recall multiple configurations).

I’m just double checking … you’re using the MidiSuite app on the laptop? Not CubeSuite, right?

http://www.cuvave.com/appdownload

espiegel123

@Gavinski said:

@Dante777 said:

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Is there any midi tool that can be used to make this behave the way I want in AUM, do you know?

Since AUM doesn't have pickup mode or relative encoding, there isn't much you can do. For apps that support relative encoding, it might be possible to write a script that would translate to relative mode if the encoders wraparound.

If you turn the encoder to the right, what happens after it sends 127? Does it send 0 as the next value?

Gavinski

Yes Jamie, is this the desktop app you checked? http://www.cuvave.com/appdownload
If not, it's worth a look.

@wim so if this can't be configured to send relative values, it also won't be able to use pickup mode in Loopy or Drambo, is that correct?

Would it be just a case of updating firmware / software for these controllers to become capable of sending relative values?

I don't even know of there is a contact email for mvave. Certainly the email I found for them the other day on what looked like an out of date official site came back as not existing when I emailed them. > @espiegel123 said:

@Gavinski said:

@Dante777 said:

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Is there any midi tool that can be used to make this behave the way I want in AUM, do you know?

Since AUM doesn't have pickup mode or relative encoding, there isn't much you can do. For apps that support relative encoding, it might be possible to write a script that would translate to relative mode if the encoders wraparound.

If you turn the encoder to the right, what happens after it sends 127? Does it send 0 as the next value?

Thnx, it just stays on 127, doesn't go to 0.

espiegel123

@Gavinski said:
Yes Jamie, is this the desktop app you checked? http://www.cuvave.com/appdownload
If not, it's worth a look.

@wim so if this can't be configured to send relative values, it also won't be able to use pickup mode in Loopy or Drambo, is that correct?

Would it be just a case of updating firmware / software for these controllers to become capable of sending relative values?

I don't even know of there is a contact email for mvave. Certainly the email I found for them the other day on what looked like an out of date official site came back as not existing when I emailed them. > @espiegel123 said:

@Gavinski said:

@Dante777 said:

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Is there any midi tool that can be used to make this behave the way I want in AUM, do you know?

Since AUM doesn't have pickup mode or relative encoding, there isn't much you can do. For apps that support relative encoding, it might be possible to write a script that would translate to relative mode if the encoders wraparound.

If you turn the encoder to the right, what happens after it sends 127? Does it send 0 as the next value?

Thnx, it just stays on 127, doesn't go to 0.

You wrote: " @wim so if this can't be configured to send relative values, it also won't be able to use pickup mode in Loopy or Drambo, is that correct?"

Pickup mode is an absolute mode thing. It means the host doesn't respond to incoming values until it receives a value matching the current parameter value.

If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

wim

@Gavinski said:
Yes Jamie, is this the desktop app you checked? http://www.cuvave.com/appdownload
If not, it's worth a look.

@wim so if this can't be configured to send relative values, it also won't be able to use pickup mode in Loopy or Drambo, is that correct?

Yes, it can be used with pickup mode in those apps. Any controller that sends 0 - 127 can benefit from pickup mode if the app has it. All it means is the app will ignore CC's from the knob until the value the knob is sending matches the value of the app control. For instance, if an app fader is at 100 and the knob is at 10 and you start turning it clockwise, nothing will happen until the controller knob gets to 100.

Would it be just a case of updating firmware / software for these controllers to become capable of sending relative values?

Yes, provided the controllers have upgradable firmware, an update is released, and the settings app supports changing the settings. The Chocolate has Over-the-Air firmware upgrades, so there may be hope.

oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
[edit] my bad. It's already been fixed.
@Michael?

Gavinski

@wim said:

@Gavinski said:
Yes Jamie, is this the desktop app you checked? http://www.cuvave.com/appdownload
If not, it's worth a look.

@wim so if this can't be configured to send relative values, it also won't be able to use pickup mode in Loopy or Drambo, is that correct?

Yes, it can be used with pickup mode in those apps. Any controller that sends 0 - 127 can benefit from pickup mode if the app has it. All it means is the app will ignore CC's from the knob until the value the knob is sending matches the value of the app control. For instance, if an app fader is at 100 and the knob is at 10 and you start turning it clockwise, nothing will happen until the controller knob gets to 100.

Would it be just a case of updating firmware / software for these controllers to become capable of sending relative values?

Yes, provided the controllers have upgradable firmware, an update is released, and the settings app supports changing the settings. The Chocolate has Over-the-Air firmware upgrades, so there may be hope.

oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
@Michael?

Thanks Ed and Wim, that's clearer, now I will have a think about whether to send this back or keep it, tho I guess there's a sliver of hope yet that there is indeed some kind of setting for these things in http://www.cuvave.com/appdownload after all

Dante777

@Gavinski said:

@Dante777 said:

@Gavinski said:
Never having bought any endless encoder controller before, I'm wondering: is this lack of relative mode a common problem? Really scratching my head at what the appeal of this knob style is, if that's the case.

I'd say the lack of relative mode encoder support in the apps is a more common problem. Some people, including me, had to write mozaic or streambyter scripts to convert relative encoders to absolute.

Is there any midi tool that can be used to make this behave the way I want in AUM, do you know?

from my point of view, if you have encoders that behave like pots, there are few variants:

• App has relative encoders support -> one can write script to convert absolute twists to relative cc messages.
• App hasn't relative encoders support, but has pick-up mode for absolute mode - pick-up should work for absolute encoder, the only problem is that you don't know which side you should turn absolute encoder to pick-up )
• App has neither relative support nor pick-up - there is no way to implement pick-up mode, afaik.

wim

@espiegel123 said:
If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

I kind of think you can as long as the encoder keeps repeating 127 and 0 and doesn't just stop putting out values altogether when it reaches those limits. It wasn't clear to me from @Gavinski 's reply how it works.

Basically, you'd just listen for decreasing values or repeated zeros for counter clockwise and increasing values or repeated 127's for increasing values, then send the appropriate relative value.

Michael

@wim said:
oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
@Michael?

Still? I thought I fixed that quite recently.

wim

@Michael said:

@wim said:
oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
@Michael?

Still? I thought I fixed that quite recently.

Off to check! I thought I checked it quite recently. 😉

wim

@wim said:

@Michael said:

@wim said:
oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
@Michael?

Still? I thought I fixed that quite recently.

Off to check! I thought I checked it quite recently. 😉

Ahh jeez. I'm so sorry. It is fixed. I guess I totally overlooked that in the release notes.
Sorry for the false alarm!

Michael

@wim said:

@wim said:

@Michael said:

@wim said:
oof ... that reminds me. Pickup mode is borked in Loopy Pro. I've mentioned it a few times on Slack, but I think it's slipped under the radar.
@Michael?

Still? I thought I fixed that quite recently.

Off to check! I thought I checked it quite recently. 😉

Ahh jeez. I'm so sorry. It is fixed. I guess I totally overlooked that in the release notes.
Sorry for the false alarm!

Cool!

Gavinski

@wim said:

@espiegel123 said:
If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

I kind of think you can as long as the encoder keeps repeating 127 and 0 and doesn't just stop putting out values altogether when it reaches those limits. It wasn't clear to me from @Gavinski 's reply how it works.

Basically, you'd just listen for decreasing values or repeated zeros for counter clockwise and increasing values or repeated 127's for increasing values, then send the appropriate relative value.

It keeps repeating them, yes

wim

omg. Weird night. I'm going to bed.
I just tried in Drambo and it appears it's broken there. I posted on the Intua forum to see if anyone else is seeing it 'cause I don't trust myself now.

Gavinski

@wim Intua Forum for a bug report about Drambo? Definitely get some sleep then, and tomorrow hit up the Beep Street forum (if there is one) 😜

Dante777

@Michael I've just tried relative encoder mode (using 1,127 relative cc values) on Loopy Pro, and have got possible problem/bug - it doesn't work mapped to the channel gain/volume (when I move encoder either way, slider just resets to zero), however works well with 'balance' on the same channel and custom gauges

Samu

@Gavinski said:
@wim Intua Forum for a bug report about Drambo? Definitely get some sleep then, and tomorrow hot up the Beep Street forum (if there is one) 😜

They definitely have one...
https://forum.beepstreet.com
...and it's definitely not a 'graveyard' like the Intua forum

jamietopol

@wim said:

@jamietopol said:
I do have the desktop software installed on a Windows laptop and I do not see any incremental options compared to CubeSuite on my iPad (other than the ability to store/recall multiple configurations).

I’m just double checking … you’re using the MidiSuite app on the laptop? Not CubeSuite, right?

http://www.cuvave.com/appdownload

Yes, that's the software I used on my laptop.

jamietopol

@wim said:

@espiegel123 said:
If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

I kind of think you can as long as the encoder keeps repeating 127 and 0 and doesn't just stop putting out values altogether when it reaches those limits. It wasn't clear to me from @Gavinski 's reply how it works.

Basically, you'd just listen for decreasing values or repeated zeros for counter clockwise and increasing values or repeated 127's for increasing values, then send the appropriate relative value.

Yes, I think this would be the best solution ("listening" for repeated 127 and 0 values is crucial).
Unfortunately, I think the holy grail will require MIDI 2.0 which supports better data in both directions. Within MIDI 2.0, I think the app can send data back to the controller. An endless encoder could have LEDs around the circumference to indicate the position (and the LEDs could jump to the new value when you load a different preset). A small screen beneath each encoder could automatically display the function it is mapped to. Now that is what I really want!

wim

@jamietopol said:

@wim said:

@espiegel123 said:
If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

I kind of think you can as long as the encoder keeps repeating 127 and 0 and doesn't just stop putting out values altogether when it reaches those limits. It wasn't clear to me from @Gavinski 's reply how it works.

Basically, you'd just listen for decreasing values or repeated zeros for counter clockwise and increasing values or repeated 127's for increasing values, then send the appropriate relative value.

Yes, I think this would be the best solution ("listening" for repeated 127 and 0 values is crucial).
Unfortunately, I think the holy grail will require MIDI 2.0 which supports better data in both directions. Within MIDI 2.0, I think the app can send data back to the controller. An endless encoder could have LEDs around the circumference to indicate the position (and the LEDs could jump to the new value when you load a different preset). A small screen beneath each encoder could automatically display the function it is mapped to. Now that is what I really want!

Midi Fighter Twister has LED rings for position and you can set the color for some help with what they're mapped to. Most apps don't provide the feedback though. I wrote a Mozaic script which can help somewhat with that as long as you only control things from the controller, not from the app.

The problem with displays and LED rings is they add significantly to the cost. The Twister is an outstanding value for what it does have.

BTW, Midi 2.0 isn't needed for there to be feedback to controllers. Controllers just need the software and indicators to process it and software just needs to send midi feedback from its controls. Loopy Pro has very good support for this.

wim

@Gavinski said:
@wim Intua Forum for a bug report about Drambo? Definitely get some sleep then, and tomorrow hit up the Beep Street forum (if there is one) 😜

wow. I wasn't even under the influence. Yeh, https://forum.beepstreet.com/. Good place.

jamietopol

@wim said:

@jamietopol said:

@wim said:

@espiegel123 said:
If the absolute values don't wrap then one can't write a script to convert absolute to relative. That is bery unfortunate.

I kind of think you can as long as the encoder keeps repeating 127 and 0 and doesn't just stop putting out values altogether when it reaches those limits. It wasn't clear to me from @Gavinski 's reply how it works.

Basically, you'd just listen for decreasing values or repeated zeros for counter clockwise and increasing values or repeated 127's for increasing values, then send the appropriate relative value.

Yes, I think this would be the best solution ("listening" for repeated 127 and 0 values is crucial).
Unfortunately, I think the holy grail will require MIDI 2.0 which supports better data in both directions. Within MIDI 2.0, I think the app can send data back to the controller. An endless encoder could have LEDs around the circumference to indicate the position (and the LEDs could jump to the new value when you load a different preset). A small screen beneath each encoder could automatically display the function it is mapped to. Now that is what I really want!

Midi Fighter Twister has LED rings for position and you can set the color for some help with what they're mapped to. Most apps don't provide the feedback though. I wrote a Mozaic script which can help somewhat with that as long as you only control things from the controller, not from the app.

The problem with displays and LED rings is they add significantly to the cost. The Twister is an outstanding value for what it does have.

BTW, Midi 2.0 isn't needed for there to be feedback to controllers. Controllers just need the software and indicators to process it and software just needs to send midi feedback from its controls. Loopy Pro has very good support for this.

I (for one) would be willing to pay more for displays and LED rings if they provided the feedback I described. I don't think the display-related feedback is part of the MIDI 1.0 specifications (but I might be mistaken).

On a related topic, I would also like my ideal controller to have at least 9 "touch strip" faders (with indicator LEDs) similar to the ones on the Vox Continental. Motorized faders are an option too, but I think they have a tendency to fail (e.g., Behringer Motor) they would be less likely to be powered via battery, and they would really increase the cost.

wim

@jamietopol said:
I (for one) would be willing to pay more for displays and LED rings if they provided the feedback I described. I don't think the display-related feedback is part of the MIDI 1.0 specifications (but I might be mistaken).

Not to belabor the point, but MIDI 1.0 only spells out communication protocol, not how to use what's communicated. It doesn't need to spell out anything about feedback because that's on the hardware and apps to implement. Everything needed for feedback is there, apps just don't implement midi out from their controls. All that is needed for feedback is for an app to send midi back to the controller when someone moves the control on-screen, but not echo it back if moved by the controller.

MIDI 2.0 implements more advanced ways to communicate between midi destinations and discover / adapt to capabilities. But even it doesn't implement any kind of automatic capability in that area. One could implement Midi 2.0 but not provide any feedback mechanism.

Sorry. Overly technical brain is having its way with me today.

uncledave

@jamietopol said:
I have the same behavior and do not think it is possible for this controller to do what you want. I think we need the knob to send CC 96 every time a knob is turned clockwise and CC 97 every time a knob is turned counter-clockwise.

I'd just like to clarify this in case anyone is confused. Those Increment and Decrement messages only apply to SysEx, RPN, and NRPN. There are a few standard RPNs that might work in an app. Virtually no apps use NRPN, though it's relatively common in more complex hardware synths. They use NRPN to expand the range of control messages; since the NRPN ID is a 14-bit value, it allows 16K possible control targets.

Relative mode for a typical controller uses a single CC, splitting the range for increment and decrement. For example, value 65 for one step up, 63 for one step down. If the knob is turned faster, numbers farther from 64 may be used, say 70 for really fast up, 58 for fast down; this indicates that you're turning faster than the device scanner can handle. Unfortunately, there are various conventions for this: up 65, down 63; up 1, down 127; up 1, down 65; up 65, down 1. It's necessary to find compatible styles for both the controller and the app that supports relative mode.

espiegel123

@jamietopol : any chance that you could post screenshots of the setup options in the desktop app for the encoders ?

jamietopol

@espiegel123 said:
@jamietopol : any chance that you could post screenshots of the setup options in the desktop app for the encoders ?

espiegel123

@jamietopol : thanks