Problem Description
Analog Labs accepts CC#28 and CC#29 as Preset Up/Down messages by default for Generic Controllers. This is undocumented/unexpected behaviour from my standpoint (as a generic MIDI controller user).
Impact
This problem made me waste a few hours doing some troubleshooting (described below). Luckily, the problem was identified while not band-rehearsing or playing live. “Undocumented features” makes the product less predictable and reliable.
My Configuration
I configured Analog Lab V with MIDI Controller to Generic 9 knobs + 9 faders with a full list of MIDI assignments. The list did not include CC#28 or CC#29 (decimal).
Troubleshooting
I started using my controller successfully with ALV by getting MIDI program changes to select the right presets. But then I noticed that ALV started to choose the wrong presets, overriding my MIDI Program Changes when changing patches incrementally on my controller. At first, I thought that my Playlist had some kind of indexing problem but then I noticed some jumping.
With a MIDI monitor, I noticed that my MIDI controller sends many different CCs when changing patches, including CCs #28 and #29. Then I tested ALV’s behaviour when sending each CC+values manually with my MIDI tool. I was able pinpoint the issue to CC#28-29 – i.e. ALV started moving up and down in my playlist.
Suggested Fix
Modify the Analog Lab behaviour so that it doesn’t change to the previous/next preset in a playlist when receiving MIDI CC#28/#29 for Generic controllers (by default). I also suggest that CCs #22-24 and #118 should also not be part of the defaults for a generic controller.
This would be likely be implemented by removing XML entries as mentioned below (for all generic controllers’ config).
Workaround
End-user modifies the default factory config with a change to controllers-common.prefmidi as described below, after the installation of Analog Lab V/Pro.
@LBH - Thanks for confirming the issue. It’s strange to me that these mappings aren’t included in the template in the UI (to make them visible to end-users). Also, some of those XML mappings (CC 22-24, 118) seem unapplicable or dangerous for a generic controller.
Anyhow, I maintain that it’s an unsolved bug (documentation gap, XML misconfig and/or missing entries in Factory: Generic (default) MIDI Config for generic controllers).
To answer your question about why these MIDI CCs are sent out, I couldn’t justify this myself (only Yahaha could but at least it’s in their MIDI Mappings doc.). But I’ve noticed that many controllers send lots of CCs when changing patches to reset different values. That’s why I feel like this documentation or template gap is a bug (from an end-user perspective).
@matjones - Thanks for jumping in bit I disagree that this is the Solution. This is just confirmation of the issue as far as I’m concerned.
@LBH - Oh wow, you sound so knowledgeable about Arturia products that I was convinced you worked for Support to help to reduce the workload on Arturia Engineering.
I do appreciate internal and external support roles very much (having been in a few myself) but sometimes, things have to reach Engineering so that things get fixed or documented (and processes improved too). So I’ll follow your advice and use Tech Support more formally. I guess I misunderstood the scope of the User Community wrt bug reports.
FYI, I can’t find this specific XML content in any of the Resources/ folders on a Mac (under Library/, “Analog Lab V.app” or Arturia/*.app/Resources/ (package contents).
On Windows i have two Arturia folders. But only one is the main resource folder. The path for the main resource folder is the path set in Arturia Software Center (ASC).
An example path on Windows is then:
Main Resource folder path set in ASC that go to the folder named Arturia/ Analog Lab V/ resources/ controllers
or another example:
Main Resource folder path set in ASC that go to the folder named Arturia/ CP-70 V/ resources/ controllers
You can try to search your system for this xml file names:
controllers.prefmidi
and
controllers-common.prefmidi
BTW: Arturia should follow the forum. But you are most certain, if you contact Arturia support.
@LBH - Nice, thanks! You helped me be more persistent in my Mac digging. I forgot to check under /Library. So here’s at least one of the paths where I could find the XML config content you mentioned: /Library/Arturia/Analog Lab V/resources/controllers/ (with controllers.prefmidi.xml and controllers-common.prefmidi.xml).
So as I understand it, for my ALV MIDI config (and my generic 9K/9F controller), I need to ensure that I have mappings that override CCs 22-24,28-29 or the control they map to. CC#118 is already overridden in the ALV UI’s Factory MIDI Config.
Summary of my workaround: Add different MIDI CC mappings (in the ALV UI’s MIDI Config) for “Previous Preset” and “Next Preset” controls so that that CCs 28-29 don’t trigger preset changes.
@EricP - I have read this thread because I am experimenting the same problem controlling Analog Lab V with a Yamaha YC61. Can you please explain in more detail your work around? My knowledge of MIDI is very basic sorry. Can you guide me on how to apply the work around? Thank you!
To me the main issue regarding programChange is the keyboard for some unknown reason send out irrelevant midi messages.
Perhaps the keyboards programChange is’nt compatible with Arturias. I don’t know.
If the issue can be helped at Arturias end, then it is and will be good. But that will not change the keyboard for some unknown reason apparently send out irrelevant midi CC messages.
Do anyone have documentation and explanation about this from Yamaha?
I can’t find any informations that’s Yamaha use midi CC#28 and 29 for anything. I can find informations about they use midi CC#00 and 32 that as i wrote is used for Bank Select.
Welcome back @frosas.
Create a user midi config in the right panel of Arturias instruments
For example assign other midi CC’s to Next/ Previous preset. I have’nt tried, but i assume that can work.
If you don’t know about midi Configs, then please create a new topic for that, so this stay clean.
@frosas - My workaround was adding those two lines to my MIDI config, making sure that Previous Preset and Next Preset were overridden (from the defaults in ALV of CC#28-29):
@LBH - IMO, the Yamaha documentation is clear enough to avoid having to reach their Support. In the MIDI CC documentation (page 54), CCs 28-29 are sent when changing EG Attack/Release on Part B (2nd layer/split) and to reset those values upon program changes – I’m not sure why to be frank. There’s some MIDI-out filtering that’s possible but not for those CCs for some reason…
In any case, it doesn’t remove the need to document/publish those ALV defaults (those you found in XML) to prevent other similar issues for other 3rd party controllers.
According to the Yamaha manuals MIDI Implementation Chart, then midi CC 0 and 32 is used for Bank Select.
Midi CC 28 and 29 is used for free Control Change. I can’t see they are used in relation to Program Change. Actually they are not able to be used as Control Change for other parameters, if they are used in a Program Change message. Effectively two midi CC’s are put out of use. So to me it’s a bug this happens - the real bug as it’s absolutely unexpected. Where in the Yamaha manual is this behavior mentioned? I have not seen it.
As i wrote in earlier post, then i would like Arturia to have better documentation, and also that they show the pre applied midi CC’s in use in the instruments midi configs in the right panel.
I would for that matter also like the full names of long parameters in the midi config at least is shown, when mouse hoovering over it. If clicking to change the parameter, then i would like the current parameter to be marked in the list of “add control”. And i would like all possible assignable parameters to be shown in the “Add control” list.
@LBH, thanks for again for your insights and for digging in the manual. I didn’t expect it but it’s appreciated.
As I understand it, some controllers (that also have hardware instruments built-in) seem to like sending out CC values for their internal controls upon program changes. It’s as if it’s generated for internal use to make sure the synth controls are in sync with the saved preset. On my Korg, I can also filter some of them out but the MIDI filtering there is also too coarse IMO (all CC-outs on or off).
I hope you’re getting what I’m saying. It’s not about sending the wrong CC to signal a program change. It’s about synchronizing the internal sound with the program number when presets are changed. Does that make sense? So it’d be a matter of filtering out CCs going out on the controller. The Yamaha has global and per-preset/per-zone MIDI filtering and the manual also goes into that. But this filtering is also too limited.
My point is, ALV has a way around these integration challenges but it requires the kind of digging (in XML) to help find it which isn’t ideal.
I couldn’t agree more. I noticed too that not all controls seem to be listed when clicking “Add Control”.
For now though, I haven’t reached a major roadblock yet, just a few workable annoyances (like any software). And I’m still hoping to keep my software instrument setup simple with Arturia-only instruments and avoiding Mainstage or Gig Performer (for now). I like shallow interfaces and simplicity.
It does’nt make sense to me, that Yamaha send out midi CC 28&29 with programChange to external gear.
As you have pointed out, then the Yamaha uses those midi CC numbers for some envelope parameters. But another instrument really can’t use those midi CC numbers at all, if they are changed with a programChange. It make no sense.
Arturia can’t do anything about that except not use those midi CC numbers.
@EricP and @LBH thanks a lot for your messages! I did the changes in ALV as you well explained. In addition, I noticed that when I transfer MIDI data to and from YC tools (a 3rd party application), the MIDI parameters are reset in the Yamaha (MIDI Port, MIDI Channel, MIDI Control, Tx/Rx Pgm Change, Tx/Rx Bank Select). So, I updated those parameters back to original values in the Yamaha and also updated configuration in ALV and now the issue seems to be resolved. Thank you!
I agree that it makes no sense. We could consider this a bug that these CC messages are sent externally (assuming they’re used internally). It helps me to think that Yamaha designs their keyboards in a modular fashion (with their own libraries) assembling modules and that they forgot to implement the proper MIDI filtering to the outside world. It also helps me to think that my Yamaha CK-61 is a lower-tier product and that we get what we pay for. But it’s not the case for @frosas with his Yamaha YC-61…
Again, regardless of that, my aim here is to help make the Arturia software product (ALV) more predictable/transparent (via documentation and/or better template), given it does support generic controllers. It’s a matter of expectations when opening it up to 3rd party integrations.
I’ll let you know what I get back from Arturia’s Tech Support…
To me, this proves my point about my Bug Report. Without proper documentation/transparency, the product is less predictable. We shouldn’t rely on other end-users doing troubleshooting to get this information. FYI, I opened a tech support case separately with Arturia Support and I’m pointing it to this thread.
Maybe add your vote to this thread? (@frosas@LBH and other readers)
