When I saw poly and channel aftertouch was an either-or, I was kind of bummed.  An engine with poly AT can itself supply channel AT and not have to be either or.  Channel AT is the "same" as taking the max of all poly AT values.  Speculatively, this seems like something that could be easily derived without jumping through hoops.  You could even zone channel AT if you wanted to and mask out getting a max value from keys outside the keyboard range of a Part.

It's difficult to believe that the Poly AT implementation paints the keyboard in such a corner that it would absolutely have to be either or.

That said, I have no real insight into the architectural limitations.  Would hope expanding the AT options would be in the cards.  

Clarification ... When I said "you could" I was referring to Yamaha developers as the "you".   And "could" was an assumption.

I have no real insight into the architectural limitations

Thanks but we are really hoping for more clarification from users around how they EXPECT it to work if both Channel and Poly AT are to be supported simultaneously. Set aside the current limitations for that purpose.

Channel AT is the "same" as taking the max of all poly AT values.

Well maybe it is and maybe it isn't.

Is that how you WANT, and expect, it to work? Or is that just how you think it works now?

What should a single key press generate: A) a Key AT event or B) a Channel AT event

If 3 keys are being held down and they are all in the AT travel area should 3 Key AT events and 1 Channel AT event be generated?

On an M8X it appears that the key travel area is divided into two contiguous lengths: the first portion of travel is for normal play and the final portion of travel is the AT travel area.

As far as we can determine the ONLY factor that determines if AT is being used is the physical position of the key itself. That is, if the key is physically in the 'AT travel area' then AT is being used. The speed/strength at which the key is moving is NOT a factor.

As long as the key is physically in the 'AT travel area' AT is being used. 

And, again as far as we can determine, an AT midi event is only generated when the physical position of the key changes AND the key is in the AT travel area. It is hard to do but if you apply enough pressure to put the key into the AT travel area and can keep it from moving then only ONE AT midi event will be generated. The next AT midi event won't be generated until the key moves - which is rather often since it is hard to keep the pressure constant in that sensitive area of the key travel.

A simplistic example of how it appears to work would be:

1. total key travel is .5 inches

2. normal key travel area is the top .4 inches

3. AT key travel area is ONLY the bottom .1 inch

4. if a key is physically in the top .4 inches of travel there is NO AT involved

5. if a key is physically in the bottom .1 inch of travel AT (no matter the speed or pressure used to actually get it there) then AT is involved.

6. If AT is involved any physical movement (regardless of speed or pressure) to a different physical position in the bottom .1 inch will generate one or move AT midi events with an event value from 1-127.

In other words it is almost like the AT travel area has its own modulation wheel - move the wheel and it generates a new value.

CAVEAT - all of the above only represents what our tests appear to be showing on an M8X. We can't determine for certain how close to reality that is.

Other instruments may work differently. The software implementation can also cause things to work differently. Some instruments may use actual 'key pressure' rather than key speed or key physical location to determine whether AT events should be generated.

Those uncertainties are why we are asking for input (to forward to Yamaha) about how people WANT IT to work.

The biggest current issue is that fact that channel AT control assignments are ignored if the performance is using Poly AT and Poly AT assignments are ignored if the performance is using Channel AT. 

There are a couple of IdeaScale submissions asking Yamaha to implement a solution that would, perhaps, make it easy to treat Channel assignments as Poly assignments (and vice versa) so the user doesn't have to manually reprogram them.

When I said "you could" I was referring to Yamaha developers as the "you".   And "could" was an assumption.

Understood - how would YOU like it to work if both Channel and Poly AT were supported at the same time? Don't even worry about what it might take to actually implement it.

Everything I expect or request is done with some sense and respect of limitations.  We all have different backgrounds and my choice of how to frame my answer is as unique as the individual I am.

I have my wish.  Use the poly AT values to derive channel.  On a per Part basis.  Add channel masking because with poly AT trickery (internally) it could be done assuming there's no architectural lock against it.

Same was in quotes because it's a generalization.  Any keyboard with Poly AT could use poly to derive channel using the (nothing special, uninspired) algorithm I gave.  I think Yamaha has this far looked at Poly as one thing and Channel as another thing tied to the keybeds on the two keyboards offered (X vs non X -6&7 vs 8).  But they all use poly through MIDI so I don't see why internally bridging Poly to channel couldn't be done.  A hybrid channel mode if you will.

Aside: More on what drives some of my personal approach (mine alone, not expected to be the approach others take.) ...

Yamaha's design culture kind of limits the solution through the lens of the designers putting the hardware as paramount.  This is why the GUI is often regarded as difficult to use because there's hardly any abstraction above the hardware implementation.  So the Yamaha keyboard experience tends to be analogous to programming in assembly for the end user as opposed to using a sleek connect-the-dots interface that's at a higher level.  The (first) Macintosh GUI experience vs Unix command line.  And this way developers relate to their own task of bringing a product to market often ignores that some amount of simple abstraction in internal code could solve lots of user problems or otherwise elevate the power of the keyboard.  For all of the creative genius there, the legacy of products past and present show blind spots and so this is the reality that any aspirational features are working against.

Nothing new here, just doubling down on my original reply and no apologies for weaving in my personal sensibilities regarding feasibility.  Others may answer differently and they have that freedom.

Use the poly AT values to derive channel.  On a per Part basis.  Add channel masking because with poly AT trickery (internally) it could be done assuming there's no architectural lock against it.

That sounds interesting - would you mind expanding on that a bit? we haven't come across any similar idea before so would like to know more about just what you mean.

How would you use the poly AT value to derive a channel? By channel do you mean the same as part number? For example does it mean be able to create range mappings similar to the current velocity ranges?

1. range #1 - poly AT values 1-20

2. range #2 - poly AT values 21-40

3. and so on

And then be able to map specific parts/destinations for each range? So range #2 might map to part/channel 5?

Everything I expect or request is done with some sense and respect of limitations. 

What are your thoughts on converting channel AT control assignments to poly AT control assignments (or vice versa) based on the selected AT mode?

Also - the suggestion to not 'worry about what it might take to actually implement it' wasn't intended to restrict anyone. It was meant to mean that suggestions/ideas/comments don't need to be restricted to what the current architecture might be capable of. 

This thread isn't about how the current M can be updated to better support AT - it is about trying to pin down the 'ideal' level of AT support users would be interested in.

Trying to take an initial 'top down' approach to identify the desired end goal. Once that is known it will be easier to know the extent to which progress, even incremental, can be made towards that goal using the current hardware.

The thought being that hardware limitations are far more limiting than software limitations. Without using plug-ins you can't really update hardware that is already in the field. But software doesn't have that same limitation.

Implementation-wise, you have two different domains.  The hardware provides "sensors" as one level and often dictates the overall limitations because you cannot re-code a hardware choice.  And then there's the software level where the options are more abundant but run into brick walls.  Not only the hardware limitations (above the sensor implementation also related to memory, ports/registers, CPU, etc) but also more intrinsic to purely software choices like some framework or coding that paints one into a corner of doing something a way that's technically possible virtually unfeasible due to the disruption of working against the chosen software "system" and would cause a big impact on, up to this point, months/years of testing.  

On the hardware front, these two forms of aftertouch have a fairly well known implementation.  Disregarding the actual implementation (inductive Poly or resistive channel -- or however you want to decide a schematic for each) - we know that at a higher level channel AT supplies the software with a value that represents the maximum amount of pressure applied to any given key.  Each key has a threshold where channel AT starts.  Past this threshold if one key is pressed then there will be a value starting at "1" (for least amount of activated channel pressure) and mashing all the way down on that single key then it will be "127" for channel AT.  These values are in quotes because they represent MIDI 1.0 and also maybe the hardware calibration doesn't allow an actual "1" or, less likely, actual "127" but those are the theoretical limits of min and max Channel AT.   If you are pressing another key past the threshold so you have two keys pressed past the threshold then channel AT will become the maximum pressure between the two.  Not the additive pressure of both - but the max.  You can observe this by lightly pressing in the channel AT zone and observing the Channel AT value.   Maybe even get a "C" clamp and get a controlled low value on channel AT on a single key.  Next, go to a second key and start to "squeeze" it.  You should recognize there's a range where the 1st key dominates (where you are equal or below the first key's pressure) then you will see the 2nd key dominate and become the maximum and the channel AT will reflect this maximum of all key result.   Physically, there's just one strip below the keys and there's only one value fed to the upstream hardware.   It's as if there's line of people all with a bar that runs the length of the line and spring loaded with 3 feet of travel of the bar.  And anyone can reach up and grab the bar and pull it down by 5 inches but someone else can pull the bar down to 2 feet and the result of the bar "pull" will become the maximum of any individual's pull. 

And still at the hardware level - poly AT we know each key gets a value and feeds it to the software.  It's the "same" as channel AT but every key gets its own value and is independent from any of the values of each key.  So we have "128" bars and each person gets their own to pull (again, quoted because of MIDI 1.0.  And also quoted because some manufacturers don't necessarily use all possible values 0-127 as valid).

So if you wanted to use software to derive channel AT from poly AT you would just take all of the values software receives from the hardware and find the maximum then call this channel AT.   Keyboards without the poly AT hardware on-board still receive poly AT messages (we're talking Montage M6 and M7 here).  So these could apply the same algorithm assuming you were using an external controller that provided the poly AT messages.  Without anything external obviously the M6 and M7 can't participate in anything with a poly AT dependency. 

Technically you could derive poly AT from channel AT -- and there's software out there that does this -- but this has too many gotcha's and I think would become confusing to support.  But essentially what you have is a system that buffers the channel value for each keypress and holds that value for the duration of a note-on event once another key is pressed.  The last key pressed would always respond to a changing channel AT value but previous notes would hold their last channel AT value.  And notes that occur at the "same time" (within a reasonable differential to be considered intended to be a block of notes simultaneously pressed) these would all buffer the same channel AT value or, as last block, modulate based on the same channel AT value.   There are all kinds of things that block you from getting a true poly AT experience - but this trickery is sometimes good enough for some.  This paragraph is a tangent -- due to the limitations and gotcha's it outside of scope of what I would want even though it's "interesting".  

So since Montage M+X (8X only currently) has the hardware to self-generate poly AT messages I would say it should use these poly AT values to get a max value.  And because software has the flexibility (assumed -- you never know the corners painted into) to say, per Part, only look at "these" keys (within some range -- or, technically, even by some map of these on and off arbitrarily set although there's no mechanism currently for such fine-grained key masking) then the max value can only include those keys that the Part is defined to be using.  And so the hybrid channel AT value can come from poly AT values but be a max value over some specific set(s) of keys (currently there is support for two zones by using a keyboard range where the low value key range is higher than the high value key range - so I say set or sets).

The M6 and M7 could participate in this kind of scheme only if you have an external controller or keyboard that supports poly AT output.   So none of this solves a problem of Performances that _depend_ on poly AT to do certain things.  Really, I'm just trying to get rid of the binary "poly" OR "channel" and get to a place where you could have both.  Both active within the context of a single Part and both within the context of a single Performance.

Because deriving values from poly AT doesn't "erase" the original poly AT values (it's a shadow register) - there wouldn't be a reason to force one or the other.

Channel AT has a potentially different value for each MIDI channel.   The message starts with 0xAn where n=the MIDI channel number 0-F (translated to MIDI channels 1-16).   So assuming two Parts are not mapped to the same MIDI channel could hold a different channel AT value.  Even internally you don't have to respect MIDI rules and could possibly have a different channel AT value for a given Part assuming the one Part at the same MIDI channel and the second Part (at the same MIDI channel as the 1st) do not overlap the key ranges.  It's simple, but not dead simple.  Which is why the current policy is implemented the way it is -- it removes the need to invest any extra complexity.   Internally, the instrument doesn't necessarily use MIDI as its addressing mechanism.  My understanding is MIDI is a layer placed at the outside doors of IN and OUT and then internally you can break the MIDI rules because the core isn't MIDI.  I believe this has been mentioned before for Montage classic.  But even so, most of what I propose is compatible with systems that would even internally be using standard MIDI as a foundational engine for everything.   On Montage, usually channel AT has the same value for every MIDI channel (i.e. every Part).  This is because we are getting our value of channel AT from one source - that only spits out one number.  However, I'm sure even today you can supply through the external MIDI bus (USB or 5-pin DIN) different channel AT values for every MIDI channel and see that these can be different.   The same kind of thing applies to the A.SW1&2 buttons.  There's only one set of switches on the hardware.  An [ASSIGN SW 1] and [ASSIGN SW 2].  So when you press the switch to light it up from the normal no-Part-selected mode pressing the switch sets the switch settings for each Part to the same values.  The same for every Part for switch 1's state and the same for every Part for switch 2's state.  However, if you set these with an external source (that isn't limited by having only 2 physical buttons) then you can toggle the switches differently for each Part.  And when you select an individual Part you can see the pattern of A.SW1 and A.SW2 change for each Part according to how you set them through MIDI (because they are set with CC and CC is on a MIDI channel basis - you're not (necessarily) setting a "global" A.SW value through MIDI).

Part of what I was advocating was levering using the key range as a mask.  But you don't have to.  It's just convenient  reuse of what's already there.  The ultimate flexibility would be to have all 128 possible keys and a way to say "participate" and "don't participate" for every key.  Roland keyboards have this kind of interface to set the velocity sensitivity for each key so you can adjust the action in a very granular way.  The downside is that to build this would add more "stuff" on the developer's plate and also would be potentially complicated to use.  I personally favor flexibility over ease-of-use and always advocate for the hard way to be buried but available and then present an easy/simplified way in front to serve the more casual users.  At any rate - you could possibly define the mask to not even be a range but literally an arbitrary mask of all 128 possible poly AT values coming in ("swiss cheese").   Since I was presenting that the easy way would be use (Part level) key range as a mask - then keys within the key range would participate in the MAX function and keys outside would be ignored.

Key range gets a low and high value.  As mentioned earlier, you get these kinds of ranges:

1) Low <= High (less than or equal to): Key range is Low Note through High Note

2) Low > High (higher value than): Key range is from C-2 (lowest* possible MIDI note) through low value and high value through G8 (highest* possible MIDI note). 

ASIDE: There's an asterisk because this is Yamaha's own definition of the octave convention.  Other keyboards shift the octave numbering differently which is just a labeling for what a hex note value from 0x00 to 0x7F means.  The hex value doesn't change but the labeling is sometimes different with other manufacturers. 

(another) ASIDE: Also sometimes manufacturers use note 0x00 to mean "silence" and not an actual note.   So this has an impact on the "128" note claim.  Sometimes it's 127 different notes do to this.  What's happening around note (MIDI value) 0x00 is hardly of any concern to most since controllers that are 88 keys don't use notes near that range in normal usage.  You have to make the keyboard shift its octave down there and loss of one note is hardly of any consequence when you're already outside of the "natural" range of the keyboard.  I think maybe Yamaha uses 0x00 to mean silence but this being wrong or right doesn't invalidate anything significant in what I've been outlining.