Hi I am still having this issue in 15.10.
I am not confident Cubase is chasing events correctly.
It’s difficult to give an exact repro, but I have a habit of looping short sections of a piece and editing articulations in the Key Editor, often the behaviour is not correct (with Snap on) and sometimes I get a note refusing to change articulation. Sometimes even in 15.10 the whole of the articulation map refuses to work at all, particularly if I experiment.
Z
Great, thanks!
I was disappointed to see that this issue wasn’t fixed in the Cubase 15.0.20 update. Do you happen to know when we might see this resolved?
Bump - wondering when we might see a fix for this issue. Thanks!
This was fixed in either the 15.0.10 or 15.0.20 update. I believe it was 15.0.10. It hasn’t been a problem for months now, regardless.
The only problem is that a lot of people are not understanding the new behaviours that were designed on purpose and are not bugs.
One behaviour in particular that people have been confusing with a bug is the new ability to lock a slot so that Cubase will stick to that slot instead of following along with the entered articulations in the music. This was requested by some people to be able to audition different articulations other than the one that they entered a passage with originally.
To lock a slot on a particular articulation you either:
A lot of people are confused by these new behaviours and do not realize that they are not bugs, especially since there is no visual indication that the slots are locked in this way.
If you read carefully my post here, what I’ve described is a bug, and was verified by @Martin.Jirsak
I am not locking a slot - The problem still occurs when using program change messages, which is not one of the two methods of “locking a slot”, as least not as you’ve described.
Unless you mean to say that, during playback, if an articulation is changed via remote Program Change, that slot is then permanently locked until playback is restarted, and any recorded articulation changes are ignored? If so, that renders the entire expression map system completely unusable for me, and I’m willing to bet, many other people. This breaks years of precedent setting behaviour.
I didn’t have a surface that could send program changes to test with, so I just loaded up Max and used a MIDI loopback. Program changes work as well, I just tested using my Max patch. Sending a program change during playback locks the slot like the others. Sending the same program change a second time unlocks the slot so it starts to follow along again with the articulations as written.
The bug fixed in 15.0.10 was that the locked state would remain and would not be cleared by stopping and restarting playback. Actually I believe the locked state sticking was partially fixed by 15.0.6 for key triggers and was fixed in 15.0.10 for program changes, if I recall correctly.
I should also clarify that nobody at Steinberg has told me outright this is not a bug, but the behaviour is very predictable and easy to work with once once you understand how it works, and it has benefical applications that directly addresses old user requests to be able to audition other articulations in this way for a previously written phrase without having to modify the entered articulations in the lanes. Between those two things, the evidence is much stronger for an intentional behaviour rather than a bug. I always ask if a certain behaviour is entirely predictable once you understand how it is working and doesn’t get you stuck in a state you can’t get out of, and whether that behaviour has some upsides (some benefits, reasons to exist). IMO, if the answer to both questions is yes, it is unlikely to be a bug. In this case, the answer is yes to both - with the mouse, toggling by clicking once and clicking again locks and it unlocks it, while with a MIDI keyboard the note-on followed by the note-off locks it and unlocks it, and with program changes, sending the program change and sending it again locks it and unlocks it. Once you understand how everything behaves, you shouldn’t end up in a situation where you have things unwantedly stuck and can’t get back out of that. And this behaviour has some definite upsides in that I know for a fact that people have asked to be able to audition phrases with different techniques without having to edit them, and this behaviour makes that possible.
And I do know for a fact that there were some related behaviours changed on purpose in this new version. Expression map slots have become toggles, and that was confirmed an intentional change. It was necessary because with the new feature of addon slots it is possible to have more than one sound slot active at the same time (this was not possible with the Cubase 14 and earlier maps design, where only one slot could be active at a given time). So you need a way to be able to turn a slot back off once it is on, and so all sound slots have a new toggle behaviour as a result.
Ok, I’ve had a chance to try it again, and it mostly works as you’ve described. If I hit play and send an articulation change (via program change) twice, it changes the articulation and “unlocks” it, so that it will continue to read and process written articulation changes.
The one exception being: If, after setting and unlocking the active articulation during playback as described above, the next written articulation is the first/topmost articulation (triggered via PC 1), it will not be read and processed.
To me, this edge case feels like a bug (@Martin.Jirsak can you please confirm?)
Without getting into a philosophical discussion on bugs vs. feature changes etc., I will say that this whole process of discovering how the updated articulation system is meant to function has been a chore. I have not found any official documentation that describes this “double-tap” functionality, or anything about “locking” an articulation. At worst, this is buggy behaviour. At best, it’s undocumented. The reality seems to exist somewhere in the middle and it falls on the users to decode which is which.
EDIT: after more testing, I’ve discovered a further problem.
With this “lock/unlock” approach where you have to send PC messages twice, a few undesirable side effects occur:
1 - the Sound Slots list in the inspector resets and does not show which articulation has been activated (and unlocked).
2 (this is the important one) - it is no longer possible to record articulation changes via retrospective record. If I press play, set an articulation twice (so that it is not locked), I can perform notes in this new articulation, but the articulation change does not get captured by retrospective record at all!
3 - It does seem to work with regular (not retrospective) record, but it appears that the “double-tap” records as a reset in the sound slots lane, which creates visual clutter.
I’m still adamant that a previous workflow has been broken in 15. It was previously possible to record articulation changes via MIDI program change, and have those articulations stick until either a new articulation is recorded, or a previously recorded articulation is encountered. This worked with regular record and retrospective record.
I was confused by this as well and assumed it was a bug. I think it’s a good feature, but we need visual feedback like a lock icon in the articulation section of the inspector, and an easily accessible option to toggle this behaviour on/off preferably next to the lock icon (with on, off and toggle key commands and generic remote access). My touchscreen automatically sets a default articulation when I select a track and this behavior is causing issues.
