New 'defaults' - Duplicate Names

Over the last few releases of Maschine, whilst there has undoubtedly been some developments and improvements, there have been some changes that are not only rather hard to fathom, but are very detrimental to some workflows.

Firstly, there was the darkened colour scheme which whilst seemingly OK on the hardware controllers, makes it very difficult for computer users to see what they are doing and slows things down considerably.
Although quite a few people also complained about this, it was completely ignored, and it looks like we are 'stuck' with it.

Of the latest changes introduced, one makes no sense to me, and is incredibly irritating. That is the defaulting to opening a new scene on Group as opposed to Sound. This also occurred with Jam. Does anyone out there really prefer this and wouldn't it be so much better if this was added as an option in Preferences?

The latest new one has completely and utterly wrecked a long-established workflow so much that it currently really isn't worth me downloading updates until this is actually recognised as being possibly unreasonable by the developer(s) and made optional.
This is the new naming convention for duplicating scenes and patterns. Whereas before, duplicating either a scene or pattern meant it was labelled as the next unused number, now it is named as the number it is duplicating with a bracketed integer behind it.

Now I know many have asked for such a convention, and it is admirable that they have been listened to, and it be implemented.
What is unfortunate is that, rather than this being optional, the established procedure has been completely nuked, annihilating long-established workflows for some. Is it really so difficult or unreasonable to ask that the original workflow be retained as an option?

I know some others feel rather strongly about this also, so if you do, or you feel that these concerns are themselves unreasonable, please voice your opinions below, and hopefully they will be heard and acted upon.

 

Yup!
This reason alone is why I won't rock Release 12 (not to mention that I find 'clips' currently obnoxious and a workflow "problem").
I agree with your suggestion of making changes available in 'preferences' as well.
PS (none of these criticisms are aimed @ Matt or Jeremy or NI support who have been super helpful to me).

 

It used to do this when my Jam was connected, but now it always defaults to Sound here, with and without Jam. Kinda strange it defaults to Group for you.

 

I agree on all points OP, well said. This honestly feels like "somebody who knows somebody asked for some things and they hooked it up" kind of updates. In no way does the new color scheme enhance anything and in no-way is the lazy man approach to the "numbering system" enhancing anything.

Seriously, what did User Stories say?

ex.
Naming Convention User Story: Change the naming system so it will not take the next number but instead, create a new counter in parenthesis next to the source object name and number.

Color Change User Story: Change the coloring system so that patterns, which have been foundational to Maschine since Day 1, will now be faded when active in the timeline.

Just typing these out feels silly.

What is worse is that somehow, some way, these user stories got scored high enough to even get worked on. This is why I say these changes were part of the buddy system, because based on ALL the other things they could have worked on, they choose these. Notice they didn't release any videos either talking about these great enhancements either. They make notes of them in the addendum but the implementation does not support the rationale. Not even close.

 

Are you talking about the Patterns being dimmed in Song mode? Dimmed things was always used to display active vs inactive, even in the hardware this is used in Pads that indicate activate things and whatnot and now it's used to distinguish Patterns from Clips in Song Mode... I don't like this either, it feels like a hacky inconsistent way to go about it.

I think the pros and cons of this might be tied to Arranging VS Composing or the different reasons users might use the Duplicate funtion. The new naming convention seems to fit better with users who manually name their stuff, this is subjective tho.

Say you have a Scene called "Verse" and dupe it, having the new dupe auto named "Verse (1)" is a lot more useful than just "Scene 2", if you dupe a few times as you arrange you can always tell by name what that Scene is originally a dupe of without having to rename them all manually to "Verse 2", "Verse 3", etc... This makes life easier assuming that when a user duplicates something the whole point is for it to be a variation of the original; this might fail if the user uses the Duplicate function as just a way to create a new totally unrelated Scene faster, which I suspect is the case for some users.

Or, say you have 8 different Patterns using default names, if you dupe "Pattern 4" the new one will be called "Pattern 9", after a while, you lose the reference of what it is / came from so having the original name + (#) can be very useful but the main con is that it destroys the workflow of duping Patterns to build a # based structure... Basically, a user might want "Pattern 9" or "Pattern 4 (#)".
Personally, I prefer "Pattern 9" if I'm building up the basics of a song and "Pattern 4 (#)" if I am Arranging; if I bothered to name the pattern then I will always prefer the dupe to have my custom name + # instead of "Pattern #".

A preference toggle would be nice or maybe the new dupe name feature should only apply when the Pattern/Scene has a custom name, not sure what would be better.

Scenes aren't bound to Groups or Sounds.... I'm lost on this one, could you explain a bit more?

 

You identified the root issue; workflow differences. I fall into the category of assigning value to pattern numbers, and this was derived based on the functionality of Maschine since I had my MK1. I learned to use their system and built my workflow around it. Since I do R&B and Hip-Hop, which is very loop-based, I can build out my base scenes, do all my patterns, then duplicate the patterns across all 16. Then it was just a matter of me going in and removing/changing elements. But I always know what Pattern 5 means in terms of song structure, and even what Pattern 15 and 16 means (any number really).

Now, I have to go in and rename every single pattern when I duplicate, because Pattern 1(I), Pattern 1(2) means absolutely nothing. I don't need to know they are duplicates based off of Pattern 1. I'm duplicating it for a reason - otherwise, I'd just re-use the pattern.

I have yet to hear a good use case for this change, because before the change, there was still a differentiator to know that the duplicated pattern is different - it had a different number assigned to it. (i.g. Pattern 1, Pattern 2, Pattern 3).

As it pertains to Scenes, the change doesn't matter as much to me, because I always renamed them anyway. I have to imagine it could pose the same problems though if people assign value to the Scene numbers.

100% agree

 

Yes, the darkened patterns are practically unreadable on a PC. It's far from being a good solution all round. I understand it's early days for clips and there's a long way to go, but there seems to be no regard or understanding that it is/was the ease of use, speed and simplicity were for many the major attributes that set Maschine apart from other solutions. It's likely to be a bumpy road ahead, I just hope that in developing, Maschine isn't going to lose what it already is.

I can see great value in the new convention and it makes sense for a certain type of workflow, I could definitely find it useful myself but it kills what is probably for many a long established workflow, making it actually impossible now to work that way. I cannot see any good reason that it can't be made an option. It's rather annoying that I and others have questioned certain aspects of development 'elsewhere' only to be seemingly ignored. My whole navigation on marking stuff out as I produce it was /is based on the previous numbering of duplicates and it makes for a very convenient workflow that is very hard to counter for.

Basically when you open a fresh scene, Group is highlighted as opposed to Sound. Jam always forced this too. It is minor but it is very irritating as I imagine most people mainly use Sound because they will be adding instruments. Again I do not understand how this isn't an option to set in preferences. Because of it previously always being set to Sound you get used to opening up and adding instruments only to find they aren't there because it has been set to Groups. Muscle Memory takes some readjusting!

 

Most music relies on repetition and that's why Maschine was so quick and easy to work with because it caters very well for that. Like you, I navigate by scenes in sequential order and knowing which pattern is which at a glance. I doubt we are the only two who are used to working that way

 

The only thing I don't like about a hypothetical preference option is that I think both naming conventions are useful depending on the Duplicate purpose, for me the ideal solution would be a pop-up dialog box asking me what name I want (old or new method) + the typical software option of "never show this again" in case this extra step bothers some users... And boom, everyone is happy.
This is the typical solution modern software uses for this kind of thing, it's common for a reason: it makes sense. IMHO

You're definitively not the only two, quite a high number of users do it that way which makes me wonder how it took this long for this issue to be brought up. I work like that too altho I start naming things later on in the production process.
PS. I edited the thread title as this seems like it will be the main discussion here, hope that's ok.

 

I completely understood what you were trying to say.

The assumption here is that someone doesn't give value to a Scene number. So for those who do, this change is a workflow change. For those who do not, they were renaming the scenes anyway, so this is no change in their workflow. Me personally, it is no change.

My initial thought is "who cares?" but I get you point. But if you are duplicating a pattern, it is probably for the purpose of making changes to the pattern, so it is no longer the same as the one you copied from. Otherwise, you'd just use the original pattern... or you can just use a Clip, right? (rhetorical question)

Ultimately, this comes down to how you build your music. If the legacy Naming Convention was problematic, I'll venture to say though that those individuals were renaming their patterns anyway to match a workflow that didn't quite align with how Maschine worked.

So basically let's change the whole naming convention just for those who want to remember which pattern they derived another pattern from. That is basically what we are saying, right? It has never worked like this in Maschine. Does it work like this on other platforms? (My assumption is that it does)

Agreed, the # based structure that they have conditioned us to. This is the crux of my issue BTW. All they did was swap problems from one group and pushed it to another, except the problem here is that there should be a greater number of people conditioned to the legacy naming system since this new one just came out less than a month ago. So this brings me back to my original presupposition that this was a change made to appease a small group of people, and probably people who have not been using Maschine for a long time and came from another platform (and probably public people who they are trying to keep happy because they help push their product). It is what it is.

NI made the decision for us. It is now "Pattern 4(#)", and this was done for all the people who need to remember what pattern they duplicated. (sarcasm)

I don't follow this logic but it doesn't matter - it is your workflow so I respect it. Obviously, you will now need to use the new Naming Convention when "building up the basics of a song", or just manually rename each one as you make duplicates. As you mentioned, a toggle would have been the better solution.

 

Indeed, that could work. What is most problematic is the seeming reluctance by the devs to comment on this, either here or elsewhere, which undermines the efficacy of the beta programme.

 

If my rather poor excuse for a memory serves, I believe it was decided to change the system to be more compatible with other DAW conventions.
But Maschine is (or was) Maschine and doesn't work like a DAW, at least not yet, and there's a whole argument as to how much value might be gained by it going full ahead down that route. Expand on its capabilities by all means but not at the expense of taking away what has been proven to work for so many.

 

I use Studio One and I don't see this behavior, but there are a ton of DAWs out there so you are probably correct.

Exactly. They like to flirt with this but they can't even implement internal-routing of midi-output on VSTs, which is table stakes for a DAW. There is a long way to go before they can supplant Studio One or Pro-Tools. Maybe Garage Band or Audacity users will rejoice.

Well said

 

This seems to be the most logical approach...

However, if there’s already a number at the end, like „Verse A.1“, it will be duplicated as „Verse A.1 (1)“, which is understandable but always requires renaming. IMO, an automatic renaming should be more intelligent and recognize patterns.

 

Agreed. You should be an assistant product manager.

Hmm... What modern software are you referring to exactly? Do you have examples or was this just a reasonable statement?

Having coded apps before (using languages like C++, which is what they use), I'd say if it is being ubiquitously done in modern software, it's because it is the easiest thing to do, not because it necessarily makes the most sense. Furthermore, if they didn't use any sort of human-centered design (and speak to a good selection of users, especially those who've used the product for awhile), it means the engineering team probably came up with the implementation on their own. They will take the easiest path 100% of the time. Additionally, the likelihood of any of the decision makers being people who've actually earned money from making music on Maschine is probably slim, so now we have people who don't really use the product making workflow decisions.

It is either all that, or this was done as a favor for a small group. It is one or the other. My money is on the latter.

As I've said before, it is what it is, and I've already adjusted. It's vastly more clicks and typing but whatever. I'm too invested in both time and $$$ to switch to another platform right now. The only power I have is to help bring down the Product Owner's Net-Promoter-Score (NPS). [envision a smirk here]

 

I feel like I am taking over the thread so I'll try not to quote too much.

I don't quite get this either tbh, it should just look for an integer at the end of the name and add +1 to whatever that value is, if there is no number then add a "2". Development wise it's just some if statements and simple math.

"Name" duped = "Name 2" (since 1 is the original without an integer? But I guess "Name 1" is ok too?)
"Name 5" duped = "Name 6"
This would keep the previous Pattern X workflow working while also having the new naming convention; I am not a UX expert tho... So might be making wrong assumptions here and there.

I am available.

I was referring to when you duplicate a track in most software, duplicate a layer or object in Photoshop, duplicate a part in 3D/CAD, Duplicate a file in any file browser, etc, etc... The original name is kept + 1 or "Copy", this is the general software convention for the duplicate function I've seen all my life and it makes sense IMO, but of course, there are cases where it needs to be smarter.

I don't think breaking the default number workflow was a deliberate thing, it seems like an oversight due to the lack of cons discussion but I can't be sure.

Not exactly, that's just one use case example, the most important part imo is retaining a custom name because duping something called "Verse" to "Pattern X" makes no sense whatsoever but duping "Whatever 2" to "Whatever 3" does make sense, regardless of the name being "Pattern" or something else, the convention could just be a little smarter and it would fix it, or have options like discussed previously.
The fact that renaming things is more cumbersome in M+ might have had some influence(?).

You said in the other thread you have a fixed workflow of using default pattern names to identify things, right? Like this:

With such a system, it seems like you could never have 5th hook Pattern since its so rigid, while with Patterns 1 (X) system it could be flexible, meaning all "Pattern 1 (X)" = Hook and all "Patterns 2 (X)" = Verse regardless of the amount that each has, the 1 and 2 could be identifiers for Hook VS Verse... So this could be (arguably and highly debatable) a more flexible system:

Pattern 1, Pattern 1 (2), Pattern 1 (3), Pattern 1 (4) = Hooks
Pattern 2, Pattern 2 (2), Pattern 2 (3), Pattern 2 (4) = Verse

Hook or verse could have as little or as many patterns as you like and still be identifiable, not sure if I am explaining this right. I am not trying to question your workflow or telling you to change it, just giving a different perspective, respectfully. This method might also break the order of how people build up song basics, which is what I meant by composing basics VS arranging.

 

I've previously been castigated for asking if the developers actually use the software, but I imagine most don't. Programmers AFAICS think in programming terms which can be so very different to the people who are actually using the software, and to my mind as well as testing for bugs, beta programmes should be also focusing on how comfortable and efficient the user experience is, because that is a huge part of what people look for in a programme.
.

In context that can work very well, as it could in some instances with Maschine, but the previous workflow could also work very well for many as was.
They are both valuable and neither should be at the expense of the other.

 

Got it. In this context, this has been the case since forever. Maschine already did this when saving the project as another name.

Well, you are nicer than me, for sure. If it wasn't deliberate, then it just shows ignorance. It is one or the other. Neither is admirable.

Agreed.

Thanks for reading that and trying to understand it.

In the scenario of hooks, I use up patterns 1,2,3,4, and always 4 bars each. This gives me flexibility to have variations in each hook since I typically use 2 for the hook. So for one hook, I can do Pattern 1 and 2. For another hook, Pattern 3 and 4. For another hook, Pattern, 1 and 3, and for another, I could do 1 and 4. Technically speaking, there are 32 combinations that I can do with 4 patterns. I typically only have 2 or 3 hooks and an outro for rap & urban, so it is plenty.

Let's talk about verses. In a rap song, you are typically going to have 12, 16 or 24 bar verses, right? Let's say I have 2 verses (which is more typical now), with extended hooks.

I can do the following:

Verse 1
Pattern 5, 6, 7, 8 = 16 unique bars

Verse 2
Pattern 9, 10, 11, 12, 13, 14 = 24 unique bars

(I'll sometimes use bars 13 and 14 for pre-hooks)

The big advantage is that I can open up any of my projects and I know exactly where everything is. I can also mix and match because I also give value to odd numbered patterns vs. even numbered patterns. For instance, even numbered patterns will have fills to lead into the next pattern. Odd numbered patterns are the top of a sequence. So, if in my outro, I want to pair Pattern 5 (from a verse) and Pattern 2 (from a hook), I know it will work. Gives me ton of options and keeps everything in order.

No worries. I've been doing this for awhile.