First it sure seems like it should be a Part rather than an Event. I mean it converts to a MIDI Part not Event. It’s certainly got a container vibe. But whatever…
More important you can’t name them anything, unlike most everything else in the Project Window. It is pretty useful to be able to select an item and find it named something useful like Chorus Percussion on the Info Line.
Also if you Copy or Repeat a Pattern Event several times, these behave like Shared Copies. Any change made to one will occur in all the Copies. Most of the time if I’m making Copies of drum or percussion Parts it is frequently to create different variations - current behavior makes that harder to do.
I don’t find it weird. When talking about patterns, many times we tend to want to recall them by an ID (using pads or other controls), similarly for example to what we do with markers/cycle markers. So, it’s a way to know which one to recall. I don’t see (for now) shortcuts on this, but I have to guess they will follow somehow. Perhaps a clip launcher? Just speculating.
Well we can consider this as an “abstract” note trigger, thus the “event” definition.
Exactly. This is the pattern repeat procedure, nothing to do with a real copy/repeat which we can edit afterwards.
This is why there is the “Duplicate” function., for editing the current pattern thus creating a new variation. I know how this whole thing feels. I personally dived into the Roland Fantom’s way of working with patterns, and I find Cubase’s way of dealing with patterns pretty similar. I guess this is how patterns work in this context
It´s very easy to modify a pattern forgetting to create another instance, what we need is the Undo button to work correctly. Now it deletes all changes made and does not revert to the previous state.
I think the behaviour as shared copy is correct but it would be great to see the 2 dashes as shared copy when there are more 1 instance in the project as a warning when editing.
a Pattern lock would be great too.
I think the pattern event is a rather different metaphor from a MIDI event.
For example, the “shared copy” is really a container for all of the different patterns of that track - and each pattern event gets to choose which of the available patterns in that track are used in that event.
And since I can name each pattern and it shows up on the event, I don’t see a shortcoming.
However I agree that additional features will be highly desirable to take full advantage of this new metaphor.
Not having “undo” is a bit painful in 2024 (having to manually save one’s desired undo steps is partying like it’s 1999. ).
But I’d hate to discourage the Cubase development team by nagging too much about this first version - because this pattern metaphor has incredible potential to be further developed.
The Sampler track also started started modestly and was iteratively developed into a much more feature rich part of Cubase. I’m hoping that a similar bright future awaits the Pattern object and editor.
That’s all reasonable within the context of the Pattern Editor itself. But when extrapolated out into the Project Window it becomes more of a problem. In the attached you can see that both the Clavi & Percussion Tracks have Pattern #1 Events. However those two sound (and are) entirely different ‘musical patterns’. I suspect that can get confusing pretty fast with a bunch of Tracks and all the items on the Tracks are labled using the same few numbers on each Track, but they mean different things on different Tracks.
In the screenshot the Perc Track’s Pattern Event is Selected and you can see on the Info Line there is no field to hold a name or description of any sort - that’s what’s missing. It is not about naming the Patterns (although I’m for that) it is about naming the objects sitting on a Track’s Timeline which hold those patterns similar to how MIDI Parts hold sequences of MIDI data - which we do name. Besides just making it easier to see what’s where, names are useful for things like PLE Presets. What should I call the things on bars 10 or 15 of the Clavi Track?
Regarding the ‘Shared Copy’ behavior, try this. Create 2 Tracks and put a 1 bar Pattern Event on each. Edit each to create a visible Pattern. On one Track drag the lower-right corner of the Event out to 4 bars. This will produce a single Pattern Event 4 Bars long. On the other Track use the middle-right control to drag this Event the same amount. This produces 4 Pattern Events each one bar long. Now if you edit the Events on either Track they are functionally the same. I think the 4 bar long Event should behave exactly like it does repeating the Pattern. But the other Track has 4 distinct copies of a 1 bar Event. I think those should be independent of each other and editing one of them shouldn’t change anything in the others unless they are specifically created to be Shared Copies. This is pretty consistent with how everything else in the UI behaves.
).