A-50 Poly AT Data 3 Octaves Too High! [SOLVED By Monkey]

[monkey man]

Yup. I've a horrible feeling I'm the first to experience this. The note component of the Poly AT data is always 3 octaves higher than the note struck.

I had a mod done years ago to make registering AT on the A-50 easier; it involved the changing of a resistor. Upon its return I checked how hard I'd have to press a key to generate AT data, and whilst still ridiculously difficult (could not be incorporated in live playing of chords etc), it was somewhat easier. I was happy with this as my greatest fear was breaking a key (it's a two-handed overdub job!). Of course, I saw no need to check the validity of the actual data generated; I simply popped the A-50 into edit mode and watched the real-time graphical readout of the pressure generated. That was 2 years ago and I've not used it since... until now.

I rang the repair station and they'd not heard of this symptom before. I'm expecting a return call next week, but the fella involved isn't huge on MIDI so I'm already concerned. Google was not my friend in this case; I can find no record of this having happened to anyone before.

For the geeks, this is the info I sent the repair guys as it's all I could find on the 'net:

Roland A-80 & A-50 aftertouch modification

I haven't tried this modification myself, so I do not guarantee this fix will work. Aftertouch may be too heavy on some earlier units. Too much pressure is needed to get aftertouch to send values ranging 100-127. Roland has announced fix for that, which consist replacing resistor with another of different value. This is done by following way:

Replace 5.6k resistor R 45 on Main A board with 10k resistor.

If you don't get satisfactory results, you may experiment with different values. On later models Roland has already made the modification at the factory.

----------

Seems that the information above is erratic. The version below has tested in real life with A-80. (Again not by me.)

According to the service notes, R43 is 5.6k for A-80 and 18k for A-50.
Its value determines the current that flows through the aftertouch sensors.
R45 is 18k.
Therefore R43 is the resistor you should replace.

There may be a record at the station of exactly which resistor they changed. I include all this 'cause nothing else has changed on the unit except for the replacement of all buttons and sliders in a subsequent submission less than a year ago (FYI a bunch of the buttons are now the wrong type!).

Hopefully someone can shed some light on this; I'm way out of my depth here. I'm already on my knees. You know the rest.

[crduval]

Hi Monkey man

I'm speaking purely theoretically here since I have no direct experience with this mod but its highly unlikely that a mod to increase range for AT sensitivity (which likely changes the ratio of contact resistance to output voltage) would have anything to do at all with pitch - unless they changed the wrong resistor or dropped a big glob of solder into the circuitry by accident.

Usually for digital keyboards (and i'm pretty sure the A50 is digital), the keyboard contacts are continuously scanned to detect key press events, so the processor would know that "key C2 has been pressed at velocity X" , but the translation of the key event data to output pitch happens purely in software.

This sounds a lot more like a global pitch transposition has been applied in software - although I assume you've already checked that.

Is the transposition happening if you play a patch w/o the MIDI cables plugged in?

Any chance you have MIDI transposition turned on in DP?

If this was a MiniMoog I could imagine that changing a resistor could change pitch - I think those keyboards worked as a resistive ladder with the key press directly creating a voltage.

Hope this helps you!

Chris


Sent from my iPhone using Tapatalk

[monkey man]

Hmm... thank you, Chris.

It's not DP (checked consoles and MIDI plug-ins). Neither is it ClockWorks or the A-50.

One of my first thoughts was whether or not the replacing of a resistor could affect the pitch reading, and from what you've said this would seem to be the case. However, why would the AT data and not the note-on value be transposed by the 3 octaves? Wouldn't the A-50's OS match the Poly Key data to the note/s struck, or is it the case that the CC info is interpreted and tagged independently of the key note number sensor?

I'm guessing that a transposition object (plug, console etc) should affect note-on and offs as well as the note numbers assigned to each Poly Key Pressure CC event, but even if some as-yet-undetected process is affecting just one of these, this wouldn't account for the 3-octave discrepancy, let alone the fact that the note-ons are indeed where they should be.

The tech's obviously struggling with it a little as he was due to call me with feedback on Monday and it's Wed evening. Heck, I'm struggling with it, although I'm just a punk.

Thank you for your thoughts, Chris. Please don't hesitate to share any minor brainwave that floats your way; you know how it goes - an innocent, seemingly-unrelated thought could well trigger the process that leads to a solution...

[crduval]

Hi MM

Just to clarify, I don't think a resistor change that affects pressure would cause your problem. In these digital days, sound, including pitch assignment is all generated in software. The keyboard scanning subsystem can tell the software which key(s) have been pressed (along with velocity, pressure etc), but the mapping of pitch to key number is all controlled in software.

If you have an exact interval of 3 octaves between the expected pitch and the one that is actually heard, that also points more to a software setting than hardware.

Like I said I don't have an A-50 so I don't know what controls are available in software to control pitch. Assuming there is one why not try setting the -3 octave transposition to correct the pitch - would that work?

I wish I could be more helpful - hope this helps a little.

Chris





Sent from my iPhone using Tapatalk

[monkey man]

Thank you for your kind gesture, Chris.

Yes, each of the 4 zones (I use 1 at a time, each set to span the entire keyboard and with unique controller assignments) can transmit on a single MIDI channel (but none can share one), and be transposed on a per-zone basis. No matter which transposition I choose, the notes are faithful to the keys pressed, but the Poly AT data isn't. The tech's obviously stumped as I've not heard from him in over a week now. I've run out of things to try; I keep finding myself re-checking the MIDI input filter in DP and the channel strips for some unseen (somehow!) plug-in or... something.

Interestingly, I thought I'd stumbled upon a solution the other day when I discovered that the Transpose plug-in offers the option to transpose (or not) the poly AT data as well as notes. If the plug-in differentiated between the two processing wise, it would be a simple matter of deselecting note transposition and setting the AT option to subtract 3 octaves from said data; it would simply follow the transpositional settings of the plug.

Hang on... [brain fizzes and blows a little steam]...

If I place two instances in series, transpose using the first up 3 octaves whilst set to ignore the AT data, then, using the second instantiation, transpose the the whole kit and caboodle (notes and AT data) down 3 octaves, I should end up in the correct octave for both data types. Yay! The theory is sound! I must win for once. Yes, yes, yes! Thanks to your communicornification, I was forced to use my edumacation and imagicanation to solve, in theory at least, a coconnunderum wherein I kept returning to the channel strips, as I mentioned earlier, as if I was missing something somehow. Fancy that, eh?

I've run out of things to try; I keep finding myself re-checking the MIDI input filter in DP and the channel strips for some unseen (somehow!) plug-in or... something.

On top of that, there's this:

Thank you for your thoughts, Chris. Please don't hesitate to share any minor brainwave that floats your way; you know how it goes - an innocent, seemingly-unrelated thought could well trigger the process that leads to a solution...

It's all falling into place. Now I simply have to manifest this in reality, and it will work; if it doesn't I'll... I'll bloody well... guess I'll keep trying.

Thank you again, Chris; the opportunity to answer your post has appeared to have produced the solution. OMG... Yay!

Off to prove myself wrong and unworthy of the Jungleville Clear-Thinking Society...

[monkey man]

Yup. I get to keep my spot on the board of the Jungleville Clear-Thinking Society.

I must transpose (up then down) to the original note range though, lest the foot sounds, which are generated through direct connection of the FD-7 pedal to the module, not match the right octave. Unfortunately I have to run the A-50 zone 4 (TD-30 and Roland I-7 control using General Purpose CCs 16-19) one octave down to avoid the aforementioned mismatch; I can't use the plugs to change the net transposition from 0 as one might expect to be able to do to make the overall kit more accessible (the aux inputs are all set to play splash and china cymbals, and they're an octave below the kick and snare, whereas everything else is generally above that - I follow the GM spec wherever I can). Obviously I have to place compensatory transpose plugs on all channels for all units (other than the TD) that I control from this zone. No worries. There're now RT MIDI plugs on every MIDI mixer strip except the VL70-m's, and I suspect, given that I use CCs 16-19 for it, that once I eventually fire it up I'll have to bung a transpositional plug in its channel too!

Something else good came of all this - I now run the TD module in "local off" mode thanks to having turned it off to try to solve the HH-note-mismatch thing. The data was doubling up (CC data only and not notes), meaning that, for instance, a quick stab at the pedal only produced a HH "splash" (open) sound perhaps once in every 3 to 5 attempts. Now it works practically every time. Yay! I win. At last, I w-i-n!!

Thank you Chris for your kind effort and kudos to you for inadvertently leading me down the path to a solution by "thinking out 'loud" when many would've just not offered anything further. I always say, news of no news is better than no news at all...

[crduval]

Ha ha - way to work towards a solution MM!

Thinking out loud (or maybe typing out loud) always works for me too. I have often begun posts to the forum and in the act of typing them out come upon an idea that lead to a solution.

My job here is done

Best,

Chis


Sent from my iPhone using Tapatalk

[monkey man]

Yeah, Chris, and how often, after pondering a problem for ages, does one find a solution during the long-overdue articulation of the problem to someone else?

I'll tell ya: Often!

Thank you again, fella. You did good.

[dojorno]

Hopping on this thread because I had the same problem with my A-80!!!

I wrote a script for Logic Pro X for the Scripter under MidiFX.

It will transpose only the Poly Pressure Data (Polyphonic Aftertouch) 3 octaves down

function HandleMIDI(event) {

event.send(); // send original event

// if it's a note
if (event instanceof PolyPressure) {

event.pitch -= 36; // transpose down three octave
event.sendAfterMilliseconds(0); // delay of aftertouch if you want it
}
}


AND that will solve it...almost. If you play A3 and A6, for instance, the aftertouch on A3 will affect A6 because it still confuses the 3 octave problem. BUT other than that, each individual note will have it's own aftertouch, LIKE NORMAL, now.

[monkey man]

Received your PM, mate.

Haven't been able to find anyone who has a clue as to how to fix the Roland. I'm amazed-and-delighted that after 6 years someone else has finally surfaced with the same issue!

God knows how we can go about getting this fixed, mate. Please, if you happen to stumble across a tech who has ideas about it, let us know in this thread!

Thanks man, and well done for finding a work-around in Logic.