Midi FX Block On/Off/Toggle

[simonp54]

Its getting close... so hoping this can be simply answered, but understand the guys are probably busy.

 

Will Helix have MIDI support for telling an FX Block to be specifically ON.  (or OFF)

 

this is usually achieved with a CC and a VALUE.  The VALUE <= 63 for OFF and >=64 for ON.

 

this would greatly enhance the product over the current rather clumsy "TOGGLE" that the HD series has.

 

Many thanks for a reply

 

Simon

[mbenigni]

This is interesting to me, since I got into a long discussion with Kemper about the fact that they only support distinct CC on and off messages, and I really wanted them to add a value for toggle.  Their position is that the MIDI spec indicates MIDI off (0) and MIDI on (non-zero).  My position was that the device (in this case Kemper) already holds state information for any given effect, whereas an outboard controller in most cases will not, so there should be a way to simply ask that an effect be toggled.  Believe it or not, this was the main reason (though not the only reason) I wound up selling my Kemper!   :o  It just became a massive PITA to make a small, affordable footcontroller turn effects on and off, especially if you are also navigating between presets ("rigs" in Kemper-land.)

 

In my opinion (MIDI spec be damned) the OS/firmware should support both.  There's plenty of bandwidth in the range of 255 values.  I.e. 0 for off, 1 for on, anything else for toggle.  Easy to implement, easy to remember, everybody's happy.

[simonp54]

I agree... i wasn't saying there "isn't" a place for TOGGLE... just it should be complemented with ON and OFF... if you have a 3rd party controller... it doesn't tend to KNOW which block is ON or OFF at preset load time...

 

The ability to be able to definitely say "ON" or "OFF" also opens up the ability for "scene" type functionality, where a floor controller sends multiple ONs and OFFs to make sure the rig is in the correct state... by ONLY implementing a TOGGLE... this is not possible with any degree of certainty...

[mbenigni]

I agree... i wasn't saying there "isn't" a place for TOGGLE... just it should be complemented with ON and OFF... if you have a 3rd party controller... it doesn't tend to KNOW which block is ON or OFF at preset load time...

 

The ability to be able to definitely say "ON" or "OFF" also opens up the ability for "scene" type functionality, where a floor controller sends multiple ONs and OFFs to make sure the rig is in the correct state... by ONLY implementing a TOGGLE... this is not possible with any degree of certainty...

 

Gotcha.  That makes sense to me.

[stevekc]

Most gear I own the MIDI CC# control convention is data 0-63 = Off, data 64-127 = On 

( The VALUE <= 63 for OFF and >=64 for ON.)

 

Thats how Roland VG-99,Boss GT-100, Vox Tonelab SE,  Fender Mustang Floor operate.  

 

If you want momentary foot swtich for Vibrato on/ off, the MIDI controller must support transmitting a separate MIDI command upon switch release 

[simonp54]

yup which kinda screams that the ON/OFF messaging should be supported... but no manual to back that up *yet*  I'd be happy (ish) even if there were specific values for doing various tasks like momentary on/off (126, 127) or whatever, because I have my own custom designed floor controller.  All that I do ask tho is that these features are "exposed" by the MIDI interface.

 

I'm hopeful Line6 won't drop the ball here, with such a great unit, it should all be available via some midi messaging.

[mbenigni]

Most gear I own the MIDI CC# control convention is data 0-63 = Off, data 64-127 = On 

( The VALUE <= 63 for OFF and >=64 for ON.)

 

I may have misquoted Kemper with regard to the MIDI spec (can't find the original email.)  Point is, they are only willing to support on/off states, no toggle command.  I would have been just as happy with alternate CC addresses that responded to toggle requests.  Anything to get an effect to respond regardless of its default state in a given preset.  Oddly, Kemper does expose one CC which toggles ALL pre-amp stomps simultaneously, regardless of their initial states, but it's kind of a hamfisted feature; not very useful in real applications.  I'm not really sure why they were willing to include that one but remained so adamantly opposed to toggling effects individually - you know, like guitarists actually do on occasion.

[phil_m]

You don't control specific effects blocks with MIDI on the Helix. You control the footswitches. So in that sense the functionality is similar to the HD series. Although, there are separate commands for "press" and "release". So you're not limited to simply toggling.

 

The other thing is that with the "learn controller" function, you can assign other CCs to any of the parameters in any block you like (up to 64 per preset, I believe). You're not just limited to the EXP1, 2 and 3 controllers.

[simonp54]

hey Phil_m... im talking about the rack unit implementation when you aren't "forced" to buy the Line 6 controller... if you are saying there is NO MIDI IMPLEMENTATION for the switching of FX BLOCKS then that is a serious mistake!!!!!

 

i understand the floorboard wouldn't "need" this kinda feature but the RACK unit will...

 

thoughts?

[phil_m]

The MIDI implementation is the same on the rack as it is on the floor unit. You switch effect blocks on and off by assigning them to a footswitch, even if it's a virtual footswitch. That again is the same way the HD rack units operate.

[simonp54]

so do we get an ON and an OFF message because in HD series we only got TOGGLE via MIDI

[phil_m]

so do we get an ON and an OFF message because in HD series we only got TOGGLE via MIDI

 

Yes, as I mentioned above, you get "press" and "release", (press is 0-63, release is 64-127) which can be thought of as being on/off. The only thing is that whether a block turns on or off with either of those commands depends on the on/off state of the block when you saved the preset. Since it's possible to have multiple blocks assigned to one switch, the on/off state of different block might be toggled opposite of each other depending on how you set it up.

[simonp54]

phil_m I'm not sure I understand why the implementation would be like you describe...

 

are you saying that e.g.

 

1) FX BLOCK is OFF in preset saved

2) controller sends CC OFF

3) the BLOCK comes ON?

 

doesn't seem to be very useful like that...

 

I can see why Line6 might have compromised to this solution based on the multiple blocks being assigned to a single footswitch, but this really means its just a TOGGLE...?

[Digital_Igloo]

so do we get an ON and an OFF message because in HD series we only got TOGGLE via MIDI

 

Currently, this is the way Helix works as well. Helix's MIDI engine is certainly capable of responding to per-block CCs with both on and off values in the future, but you'll want to add this to IdeaScale.

[simonp54]

SO just to be sure... DI, you are saying it is currently a TOGGLE... like HD series...?

[simonp54]

I have added idea to ideascale as Idea#2602  http://line6.ideascale.com/a/dtd/HELIX-MIDI-implementation/781277-23508

[duncann]

This midi stuff sure is confusing.

 

So there are two modes for a switch, a toggle and a momentary mode. Is this correct?

 

For momentary mode, there is a CC#, say 55 for switch5, with the value range split in half to indicate when a block(s) assigned to switch5 should turn on or off, like phil said above. So if using a DAW, or other method, to control Helix, sending a value of 0-64 using CC55 will turn whatever is assigned to switch5 on, even if it's already on (if it's off it turns on), and stays on until it receives a CC55 with a value 64-127, at which point it turns all assigned blocks off, even if some blocks were originally on. Is that the mechanics for momentary mode?

 

For toggle mode, is there a different CC# where any value sent, 0-127, just toggles any assigned blocks? Or what determines the mode a switch is using? Are the different modes even applicable to midi? Am I over-thinking this?

[phil_m]

I found out I was sharing info that was from an earlier version of the manual. There aren't separate commands for press and release. The appropriate CC just toggles the footswitch (or in the case of the rack unit, the emulated footswitch).

[simonp54]

I found out I was sharing info that was from an earlier version of the manual. There aren't separate commands for press and release. The appropriate CC just toggles the footswitch (or in the case of the rack unit, the emulated footswitch).

 

in that case is momentary mode implemented with a different CC number?

[Digital_Igloo]

in that case is momentary mode implemented with a different CC number?

 

Nope—your foot controller would need to transmit a specific CC for both press for release. If your controller can't send a CC on release, how would Helix or Helix Rack know when you've lifted your foot?

[simonp54]

Nope—your foot controller would need to transmit a specific CC for both press for release. If your controller can't send a CC on release, how would Helix or Helix Rack know when you've lifted your foot?

So DI this is where the confusion sets in...

 

Is there ONE or TWO CC messages involved here?

 

if it is ONE message then I infer the following (please correct me if i'm wrong)

 

CC sent with 0-127  ----> HELIX interprets as TOGGLE (IF FX BLOCK is not a momentary)

                               -----> and or HELIX interprets as OFF <=63 and ON >=64 (IF FX BLOCK is a momentary)

 

the important thing here is that the CONTROLLER needs to be in control... AKA if it sends ON, then HELIX should make sure it is ON, if the controller sends TOGGLE then HELIX should toggle it...  HELIX shouldn't impose any "rules based decision" when reacting to a MIDI message.  (excepted that this creates an issue with multiple fx blocks on the same "footswitch", however can be considered ON or OFF as a group with their initial states flipped if necessary)

 

Like i said in the ideascale... The midi implementation should be separated from the "HELIX" logic.  I would have HELIX expose its "core" functions via the MIDI interface...  The way the product works "out of the box" via the internal features could be different to the way it reacts with a 3rd party controller.

[mbenigni]

Agreed, this is getting confusing.  If I'm not mistaken, DI's most recent reply contradicts Phil_M's most recent reply.  Safe to say DI's is accurate?  Having separate messages for press and release definitely seems like the more versatile implementation.

[phil_m]

I believe what DI is saying above is that they got rid of the need to send different values for press and release because they were worried about people using controllers that couldn't send unique values with the press and release of a footswitch (which I think would be most controllers). So they just changed all the CCs that emulate footswitches back to toggles.

[Digital_Igloo]

Remote footswitch emulation (which is in Helix) responds to specific Global CCs. For example, sending CC50 to Helix (any value) emulates Footswitch 2. If you want to engage a switch momentarily, your controller should send any CC50 value upon press, but send a second CC50 (again, any value) upon release.

 

This is different from per-block bypass via CC, which, if ever implemented, would assume reception of different values for enable (64-127) and disable (0-63).

[mbenigni]

Oh, OK.  I think I've finally got it.  :)

[simonp54]

Remote footswitch emulation (which is in Helix) responds to specific Global CCs. For example, sending CC50 to Helix (any value) emulates Footswitch 2. If you want to engage a switch momentarily, your controller should send any CC50 value upon press, but send a second CC50 (again, any value) upon release.

 

This is different from per-block bypass via CC, which, if ever implemented, would assume reception of different values for enable (64-127) and disable (0-63).

Thanks DI, that does clear up not only the current implementation confusion but also the way you see it "if" implemented.

I also note that you are talking about the "remote footswitch" being the feature being exposed, which obviously inherits some "HELIX CORE" functionality/baggage...

not an FX BLOCK control...  all makes sense... all fits with the product line(s)... but could be improved...  ;-)

[Digital_Igloo]

I also note that you are talking about the "remote footswitch" being the feature being exposed, which obviously inherits some "HELIX CORE" functionality/baggage...

not an FX BLOCK control...  all makes sense... all fits with the product line(s)... but could be improved... ;-)

 

I can't stress enough how tightly wound Helix Control's cap-sense switches/scribble strips and Helix Rack are. Attempting to shoehorn in a third-party foot controller is completely missing the point. It's like buying a Tesla P85D and then deciding to pull it with sled dogs.

[simonp54]

DI please... come on... I can't stress enough how I'm not gonna spend an additional £500 on a floorboard I already pretty much have that is gig proof...  Oh and I own all the code for... and IPR etc...  I don't care during a show whether it says "BOO" or "T808" or whatever... and im sure as hell not gonna be using the cap sense during a gig.

 

I am a bit surprised you have "put down" 3rd party controllers like this...

[Digital_Igloo]

DI please... come on... I can't stress enough how I'm not gonna spend an additional £500 on a floorboard I already pretty much have that is gig proof...  Oh and I own all the code for... and IPR etc...  I don't care during a show whether it says "BOO" or "T808" or whatever... and im sure as hell not gonna be using the cap sense during a gig.

 

I am a bit surprised you have "put down" 3rd party controllers like this...

 

Nobody's putting any products down. The cap-sense switches, RGB LEDs, and scribble strips are a HUGE part of what makes Helix Helix. It's how you get around. It's how you edit. It's how you control parameters live. It's how you know what's going on. It's why your tones can be more creative. It's why you can make tones in 30 seconds instead of 10 minutes. It's why you have more confidence while performing. It's how you'll be able to take advantage of certain unreleased features, including those we haven't dreamed up yet.

 

Our remote isn't notably better by itself (in fact, right now it's worthless without Helix Rack)—it's simply designed to extend Helix floor's countless advantages to Helix Rack. We're not going to undermine all the UI/UX work we've done—and spend untold hours and resources doing so, at the expense of adding to and improving existing features—just to make it easier for people to not buy our products.

 

I mean—how would I pitch that to the rest of the company?

 

There is, however, an advantage in making it easier to control Helix Rack from a DAW via MIDI or USB, so some overlap isn't outside the realm of possibility.

[simonp54]

Hi DI,

 

I didn't start out to have anything like a "negative" exchange about this fantastic looking product... I have a particular viewpoint which is probably shared by a number of potential customers of "Helix".  So please don't imply that I want to undermine or criticise the work that you guys have done, which I think from a product centric perspective is excellent.

 

My original question was a fairly "minor" bug bear of mine and actually now I think about it, it is one of the reasons that I don't use my DAW to control HD PRO X, because it gets confused very quickly between device state and requests from the DAW (I'm talking during playback/take recording etc, think looped section where there is a footswitch toggle in the middle)

 

I sincerely hope that the unit ships soon so that, we the consumers, can get a handle on what it can and can't do "out of the box"...