Global Patterns

[DivinEviL616]

This seems to be making life more complex again, not easier. Digging into menus can be a PITA. Some simple structure could be handy but making it too complex and forcing people to go into it too often is just robbing Peter to pay Paul, I think. It might keep the Luddites happy but it wouldn't necessarily make things easier for the rest of us.

There are a few reasons why I feel this suggestion makes this 'concept' easily implementable as well as it's implementation a moot point for the people who disagree (and that includes the part of myself that would rather not support the idea in favor of things remaining the same).

You used the term 'modus operandi' in another discuss you and I had, and that term got me thinking a little bit because I'd recently had a random thought on the term and decline in the use of classic Latin phrases in modern this English speaking society and how even I had recently let them slip from my own vocabulary - so the fact that you used one so soon after my contemplating that very topic suggested that perhaps the Universe was screaming at me again and I should turn the volume down to hear what it's trying to say.

I was thinking about the underlying modus operandi and the implementation of features, especially those revolving around the pino roll such as the length option. It's a simple Menu function. Granted I believe this to be an aspect of Orion that is double edged in its wisdom. It keeps the Orion's user environment (and by my logic this extends down into the coding as well making it a part of Orion's smooth operation) but on the other hand they aren't presenting themselves too explicitly and therefore get overlooked; either way all this talk about GUI and virtual folder, pattern pools are all things that make a person envision the feature in the context of its visualization over the ultimate function. The visualization works directly against Orion's MO and this is what I believe to be the cause of about 75% of the disagreement and 80% the cause of the misunderstanding. So for the purpose of cutting out the bullshit, lets pretend it's already there in the program and how it would look if it were a part of the current system.

This is how I believe Richard would have presented this feature based on how I understand Orion as of right now:

In the Piano Roll of the Generator receiving the imported data (can even be set up to include the generator exporting the data and not need to have a specific PR focused) you would click 'Edit' on the Menu Bar.

It drops down the list of options and somewhere between 'Humanize and 'Add Pluck Template' there is something listed 'Pattern Import/Export' and you select it.

A small window pops up in the center of the center of the screen. You select from a list the generator that the piano roll data is to be sent. Then you click the optional data bubbles below a dialog that reads Inclusde: 'Velocity' 'Modulation Data' etc. that will be sent along with the simple notation data to the receiving Piano Roll. Then you select from another list the Generator you want the information sent to.

Then you click 'Ok' and the window disappears and everything is how you commanded.

In other modifications of this you could include a simplified dialog to import all 'bank data' from one generator to another.

This effectively 'pools' all your patterns without having to actually have a physical representation of it anywhere; and even if you add an Import/Export button to the piano rolls GUI pissing off the people who 'would never do such a thing'. I will personally break down and and skin them a new default that does not include the additional button. Unfortunately they will have to learn to accept its existence in the Menu Bar's Edit Tab - but that might be healthy for their mental well being in the long run.

YOU SHOULD ALL PAY ATTENTION HERE RIGHT NOW:

Those pyromaniacs over at KVR have won and have been proved 'right' by this thread. The only difference is that you're not attacking a newbie but rather have cannibalized yourselves by gnawing at each others ankles. A good amount of this is healthy for the strength of the community and the validity of the concept in discussion, but it's gone too far, and I have made at least one or two suggestions in here that I felt were pretty valid and as far as I know the only one to actually entertain them has been Bones, and to a minimum of merely saying 'sorry better luck next time' - but I will check on this and edit accordingly if I am wrong but it really feels like I'm just posting into wind for the entertainment of the evil duck that has been pulling the strings of strife. So I guess all in all, those idiots at KVR have been right and the only reason to pull this into the public view has been to equivocally say

"Yep after nearly 20 pages of bullshit and defending ourselves against this very allegation, we just wanted to let you just how wrong you really were - cause we're bigger assholes than you had actually claimed! SEE! "

When I finally caught up with that fleeing duck from yesterday he told me evil duck would make sure that something like this would happen and I wasn't even going to present his suggestion at all because it seemed that it only existed just so you could keep arguing about it...Then a quick memo from my 'business thinking' department tells me that new functions should not only satisfy the needs of existing customers but attract new ones as well.

So what the hell? I'm already in Samurai Mode might as well give it one more for the sake of futility....so I'm calling evil duck out on this one....

[bones]

Boy you're really reaching there Bones..that's the best you can do?

C'mon, if anyone is "reaching" it is the person who makes a suggestion they admit is a bad idea, just to try and derail a discussion. Either that or you think that having a feature there is more important than getting any benefit from it, which is even worse.

I said might be a compromise...you know in an effort to maybe satisfy both sides....no actually you wouldn't know about compromise what was I thinking?

How would it be a compromise when it would effectively destroy all the reasons for making any change at all? i.e. How is creating more separation a compromise for a system that is trying to reduce separation?

[Teksonik]

Boy you're really reaching there Bones..that's the best you can do?

C'mon, if anyone is "reaching" it is the person who makes a suggestion they admit is a bad idea, just to try and derail a discussion. Either that or you think that having a feature there is more important than getting any benefit from it, which is even worse.

I said might be a compromise...you know in an effort to maybe satisfy both sides....no actually you wouldn't know about compromise what was I thinking?

How would it be a compromise when it would effectively destroy all the reasons for making any change at all? i.e. How is creating more separation a compromise for a system that is trying to reduce separation?

I wasn't trying to "derail " your pointless discussion I was trying to search for some common ground..even though Rich said it wouldn't work and I have to agree with him.....So yes I was reaching for something that might satisfy both sides. Something that you will never do.......

it would effectively destroy all the reasons for making any change at all?

There is no reason for making this change at all...a point you'll just never get.....

So you are suggesting something you don't think is a workable idea?

What's any different than you suggesting an idea you think will work but obviously [/i]won't[/i] ?

[Mark]

The thread is going in circles in an non-constructive manner. I can't imagine Richard is going to read through all this, so the point of the thread is mostly lost.

Unless it moves to something more constructive then I'm afraid it will have to be closed and the circular arguments removed. I'll give it until late tonight (GMT) for people to either do that and/or summarise what they think of the idea.

[Teksonik]

Why? I keep asking you and Lance and all I get is this rubbish. Give me some cogent reasons, nothing you've said so far makes me think there will be any issues at all.

I've already given you my reasons against Global Patterns. You simply will not listen as your ego prevents you from admitting you are wrong.....How will older projects be loaded? As Rich suggested...1_A_1 and 2_A_1 and 3_A_1 and 5_B_6 and they will live with pattern 84 and pattern 536? What an incredible mess. And don't just assume Rich can find some easy solutions to every one of the problems this idea will create just by waving his Magic Wand..it's going to take a lot of work to devise a system that completely changes Orion's workflow without breaking older songs and becoming a complete organizational mess. You can read his enthusiasm in this thread....or not...... What about Song merge? No sorry, Global Patterns bring nothing new to the table and destroy Orion's strongest point.....not worth the effort.....

There is no "patterns per generator" workflow, it is simply a feature of Orion's pattern-based workflow that confuses many new users and can be restrictive for all of us.

What a ridiculous statement. Of course there is a Pattern Per Generator workflow. If you had used Fruity's Multiple Generators per Pattern workflow you'd know there is a difference....Restrictive for all of us? Yet you've lived with it happily for over a decade and spent that entire time telling new users they should learn to adapt to Orion's methods or they are Idiots....If you think the current pattern system confuses newbies wait until they encounter the disaster that would be Global Patterns.....

Orion's Pattern Per Generator workflow is why I use Orion and why I won't install any new version on my studio computer that breaks that workflow.....

We usually need just two banks, A & B, for drums and almost never use more than 8 patterns anywhere else

And that gets to the heart of the problem. You work in a very simplistic way and just can not comprehend that others work in different more complicated ways. For simple projects like yours Global Patterns may not be a problem but for the user that employs dozens of instruments and hundreds of patterns your idea will turn Orion into a complete nightmare of an organizational mess. You can't see that because you can't see past your own limited way of working.


EDIT: Mark has posted while I was writing this. Yes I agree things are going in circles and I apologize for my contributions but it's not like this is the first time feature requests have gone this way...it's just the roles are reversed this time.... I've made my last case against Global Patterns....Neither side will convince the other at this point.

In fact let's go ahead and add them to a new Beta because I could use a good laugh. Then when we all see how pointless the idea was we can go back to using 8.5 and all live happily ever after........I'm done here.

[HYPNAGOGIA]

Guess I'll chime in, while it's still open.

It's been quite hard to follow the entire discussion, long posts and endless attempts to explain the whole thing better didn't really contribute to my better understanding, but from reading here and on the beta forum, I guess I have enough to form an opinion. Feel free to correct it if you feel that my opinion isn't in quite place. But keep in mind that even I admit that I don't have a full picture of it just yet.

So, where to actually begin...
First of all, I'll say that the current pattern-based workflow actually works for me, but that doesn't mean I don't see merits, or at least something good with the proposed global patterns system, along with concerns, so I'm pretty unbiased about the whole thing. I'm still sort of on the neutral ground - liking both systems, but that doesn't mean that I don't have concerns about things from the things I've read.

One thing that I consider positive about global patterns is the easier sharing of patterns (where you need them) comparing to the current system. I have to say that I really rarely share patterns between generators, and when I do, it's usually for the same instrument, or if I share (copy) patterns onto another, it's for further modifications on the designed theme. So far, the way things are now has worked for me, since there is more than one way to do it, and whatever you pick to do, it will do the job it's intended to do. But I actually prefer to make each instrument have its own set of patterns rather than copies of another. That's just me, plus I tend to use longer patterns (from 16-32 up to 256 long) rather than many of them, though for just the kick alone, I can fill up an entire bank sometimes. Someone else most probably copies patterns from another generator and work from there. Whatever the cause, I think it's been working fairly good so far.

Now, regarding all this, two main concerns arise; organization and events, although both could easily fall into the organization category.
We've all seen how events transpire now when you copy a pattern, it's more evident if you copy patterns between two generators (Wasp -> Toxic, or whatever). Doesn't always turn out good (in the previously stated case, a Cutoff event on Wasp -> Velocity on Toxic) and personally, I'm the kind that doesn't want all events to be the same (and we know how editing long events is 'easy' right now), so the question with global patterns is where and how the events are stored, and how they transpire when you take a pattern that has such events and put it on another generator. Ideally, they would be placed on the same type of controls (Cutoff -> Cutoff, Velocity -> Velocity, etc), but we know that's not the case, and is most likely very hard to achieve, if not impossible. I am fine with that, I don't expect everything to work automatically, and instead utilize some of the "God-given" thought process. After all, you have to be able to think things through to get something done, if you expect everything to do things for you, well, that just doesn't turn out good. So, I'd have to say that in this case, I'd actually prefer events to be discarded. Why? Well, editing long events can be painful as we all know, and what is the real point in having an event that will just ruin your setting on the instrument the moment you apply it.

The other thing, and I think it has a pretty big impact on the general perception about the whole thing, which is what I think bothers most people who oppose it at the moment: pattern organization, which comes as a major issue with several sub-issues on its own.
Implementing just global patterns (ie. all patterns available to every generator) would just create confusion and mess. Considering there are people who use great amount of generators, it can get quite confusing. Taking a person who works with 20 generators (there are people who use much more), and let's say the fill just one bank on each (varying the number on generators - somewhere it will be more, somewhere less, but let's make it consistent on all), that's 160 patterns already. Person using 30 will have to deal with 240. Without renaming each and every one of them, there's no way to tell which pattern is what. And as Bones said somewhere, it's a computer thing, not a music thing. Take into consideration the events translation issue, and you have a major mess to deal with to the point where it would be just easier to start a new project... or would it, if you'd have to deal with all of that all over again.
As a sub-issue comes the question of editing. In a discussion when Automation Tracks (ATs) were still considered, there's been discussion about patterns as well, and possibility to switch to clip-based system, but the major problem was editing. Namely, if you change one pattern, it changes every and all patterns where such pattern is used. So the question is, would that be the case here? I certainly wouldn't want to assign the pattern on another generator and modify it, only to discover that the original has changed as well. That would be "one step forward, two steps back" in the true sense of the meaning. There would have to be a function that would truly copy the pattern, not just use a pattern from the pool, but we already have that, don't we? The proposed (can't remember who proposed it, though) organization system just reminds me of the one FL has... waste of screen space, IMO, and would require drag-n-drop method to have any usability... or at least double-click for assigning.

Bones, I really hope you will understand this as a genuine attempt to understand the whole thing. You are debating that global patterns would solve issues we currently have now. I am trying to understand what issues you're referring to.

[bones]

I was thinking about the underlying modus operandi and the implementation of features, especially those revolving around the pino roll such as the length option. It's a simple Menu function. Granted I believe this to be an aspect of Orion that is double edged in its wisdom. It keeps the Orion's user environment (and by my logic this extends down into the coding as well making it a part of Orion's smooth operation) but on the other hand they aren't presenting themselves too explicitly and therefore get overlooked; either way all this talk about GUI and virtual folder, pattern pools are all things that make a person envision the feature in the context of its visualization over the ultimate function. The visualization works directly against Orion's MO and this is what I believe to be the cause of about 75% of the disagreement and 80% the cause of the misunderstanding.

I understand what you are getting at but in this case the language you use is vitally important in understanding the concept. I have very carefully avoided using the term "pattern pool" because it conjures up an impression of something separate that needs to be connected with each instrument. I am 100% certain that is where both Lance and Teksonik went sour on the idea, which is why I have not used the term in this discussion. If I was not such a selfish old man I'd probably have thought to use a term like "shared patterns", which is much more descriptive and invokes the right warm and fuzzy feelings in those who read it.

So for the purpose of cutting out the bullshit, lets pretend it's already there in the program and how it would look if it were a part of the current system.

I think I've given several detailed descriptions already.

In the Piano Roll of the Generator receiving the imported data (can even be set up to include the generator exporting the data and not need to have a specific PR focused) you would click 'Edit' on the Menu Bar. It drops down the list of options and somewhere between 'Humanize and 'Add Pluck Template' there is something listed 'Pattern Import/Export' and you select it.

No, already you fundamentally misunderstand. There would be no importing or exporting. Once a pattern was created, it would simply be there to use. Its just that instead of only being there for the instrument you used to create it, it would be available for every instrument. Instantly. Automatically. No importing or sharing or copying or connecting. Every pattern visible to every instrument, in every situation. Otherwise there is no point as copy/paste becomes just as effective.

A small window pops up in the center of the center of the screen. You select from a list the generator that the piano roll data is to be sent.

Stop it! Now it is measurably more effort than copy/paste and absolutely no-one would use it.

Those pyromaniacs over at KVR have won and have been proved 'right' by this thread. The only difference is that you're not attacking a newbie but rather have cannibalized yourselves by gnawing at each others ankles.

It would be more than a little hypocritical to behave otherwise. We are all passionate about Orion. We all get that and I think it's great (up to a point) that Teksonik and Lance get so fired up. Of course, they're completely wrong this time but the alternative would be for them to shut-up, in which case I wouldn't have had to put so much effort into thinking every aspect through so carefully. i.e. They have pushed me to come up with the best idea I possibly can. Otherwise, I'd have just re-posted the original idea from KVR and we'd have had a discussion consisting of "+1" and "-1". I think we can all agree that would not be useful for anyone or Orion.

...it really feels like I'm just posting into wind for the entertainment of the evil duck that has been pulling the strings of strife.

I can't see how you would get that impression. I've read all your comments thoroughly and answered fully, where appropriate. Tek and Lance have switched off where this idea is concerned and we're not going to get them back until they get to use it for themselves. Sometimes that happens.

So I guess all in all, those idiots at KVR have been right and the only reason to pull this into the public view has been to equivocally say
"Yep after nearly 20 pages of bullshit and defending ourselves against this very allegation, we just wanted to let you just how wrong you really were - cause we're bigger assholes than you had actually claimed! SEE! "

I don't think I ever suggested they were wrong in their description of what goes on, just in their interpretation of it and their reaction to it. If you want to see it as a steaming pile of negativity, then you are misinterpreting things. If I have anything to do with it, it is a healthy debate, although sometimes I find it necessary to drag things out of people who think that "I don't like it" or "this is a really good idea" is some kind of persuasive argument. As I said at KVR, I don't see any reason at all to treat people on forums any differently to the way I'd discuss things with my colleagues at work or my mates at the pub. It just seems that when you write things in a forum people somehow think you are talking directly to them, rather than to everyone at once. e.g. Right now I am responding to something you have posted but I'm writing it in the expectation that it will be read by everyone, so it is not directed at you specifically and, no matter what's written, there is no reason to take even a word of it personally. If I want to call someone a dickhead, I'll call them by name.
I know this is massively off-topic but it is something that annoys the hell out of me as it stifles discussion far more than me calling someone an idiot for making a poor argument.

[bones]

How will older projects be loaded? As Rich suggested...1_A_1 and 2_A_1 and 3_A_1 and 5_B_6 and they will live with pattern 84 and pattern 536? What an incredible mess.

How will that be a mess? I imagine they would be sequentially numbered, 000 to 027 or something, not randomly spread out from 000 to 10,000. It is no messier than you giving Pattern C4 a name like "Bassline 12", is it? If its an old project, then you'll probably have an arrangement in the Playlist which will show you exactly what is going on. I really can't see where any problem is here. It is no different at all to the current situation. If Sik gives me a song he's made and there are 20 Wasp patterns (and there sometimes are), I have no way of knowing what each is for, except the Playlist shows me what goes where. Even if it is a project with a 20 instruments (also common), I don't see that it would be any harder with global patterns, in that knowing that a particular pattern goes with a particular instrument still doesn't tell me what it's for.

And don't just assume Rich can find some easy solutions to every one of the problems this idea will create

But so far you've only come up with one problem and it's kind of not really a problem at all. In any event, are you saying we should never make any suggestions, just in case Rich is too stupid to implement them properly? I have somewhat more faith in RIch than that.

it's going to take a lot of work to devise a system that completely changes Orion's workflow...

Unless it is implemented very differently to the way I have described it, there will not be any change to Orion's workflow at all, just to one or two tiny mechanical details. Everyone should be completely free to continue to work just as they always have.

What about Song merge?

What about it? It is a feature I first requested in 2000, that no-one else showed any interest in at all, that finally got implemented in 2011. In fact, it is a good example of why I am right here. I originally requested it because it is an enormously useful feature in 3DS Max that I knew would translate very well to Orion. Similarly, I have used global patterns in hardware sequencers since the late 1980s and I understand their strengths and weaknesses in relation to patterns-per-generator, so my argument is based on real-world experience, unlike yours, which is pure speculation.
Song Merge would be nicely complemented by global patterns, as they are quite different things. Merge copies everything from a particular channel, whether you want/need it or not. It can also load stuff from any other song, which is where it could work really well with Global Patterns for remix work.

Of course there is a Pattern Per Generator workflow.

I think you misunderstand the word "workflow". Its kind of like tactics and strategies, or techniques and skills. Workflow is a top-level concept, so the workflow in Orion is pattern-based and mixer-centric. Patterns-per-generator is simply a feature within that workflow, not the defining aspect of it. i.e. removing patterns would change the workflow, re-organising them slightly will not.

If you had used Fruity's Multiple Generators per Pattern workflow you'd know there is a difference....Restrictive for all of us?

I've not but knowing Gol, I sincerely doubt it is anything like what I'm proposing here. When my bandwidth resets tomorrow, I'll download the demo and check it out. Have you got a file I can use to see where it falls down?

Yet you've lived with it happily for over a decade and spent that entire time telling new users they should learn to adapt to Orion's methods or they are Idiots...

Only where they have made stupid suggestions based on their inexperience. As you say though, I've had a long time to learn how Orion works so I am aware of all its' good and bad points. Yes, I've learned to live with them but that is not to say everything is perfect and nothing can get any better, ever. Its also not about me, it is about Orion and I think it is the first impression a new user gets that will be most improved with Global Patterns. I'll adapt, as I always do when things change.

If you think the current pattern system confuses newbies wait until they encounter the disaster that would be Global Patterns.....

Hang on, your complaint centres around old projects. Newbies, by definition, won't have any of those so they should be fine.

Orion's Pattern Per Generator workflow is why I use Orion and why I won't install any new version on my studio computer that breaks that workflow.....

Neither would I. I took that stand over Automation Tracks and I was shown to be correct. I'm not a betting man but I reckon the odds are pretty good I'm right here, too.

We usually need just two banks, A & B, for drums and almost never use more than 8 patterns anywhere else

And that gets to the heart of the problem.

Only if you quote me out of context.

You work in a very simplistic way

No, I work very, very hard to keep things simple. It is not the same thing at all. Do you have any idea how long it takes me to go through one of Sik's 20 instrument songs and turn it into something manageable? Of course not, because that is a process you never put yourself through. Part of my workflow also involves spending literally thousands of hours re-skinning Orion so that it is easier to work with and even more time making my own instruments, which allows me to keep things simple when I am working on a project, where it is vitally important. The easier route is to use stuff off the shelf, to keep adding krap until you're happy, layering up instruments and piling on effects. It is much harder to make sure that you have the perfect instrument for every part, only the parts that make the song better and only those effects that actually contribute to the end result. Getting all that stuff just right is why it usually takes me 3 to 6 months to finish just one song. It also makes my workflow far more complex than yours or anyone else's, even where the song has been given to me by my bandmate and I've not had to create anything for it (maybe especially then). That you see an end result which you perceive as simple, and hopefully elegant, is proof that my workflow is effective.

... and just can not comprehend that others work in different more complicated ways.

I certainly can, which is why I think you're all indolent idiots, after a quick fix and largely unwilling to put in the required effort, but that's a discussion for another day.

[bones]

We've all seen how events transpire now when you copy a pattern, it's more evident if you copy patterns between two generators (Wasp -> Toxic, or whatever). Doesn't always turn out good

It doesn't turn out at all. Automation is not copied with patterns. You only get note data and velocity, everything else is stripped out. I asked last week whether that had always been the case but I got no response (I avoid automation like the plague).

I'd have to say that in this case, I'd actually prefer events to be discarded. Why? Well, editing long events can be painful as we all know, and what is the real point in having an event that will just ruin your setting on the instrument the moment you apply it.

That is only true in certain cases. i.e. Where you are copying a pattern for the purpose of making changes to it. What if you want to try out a different instrument on a part? You won't know until you try whether the automation will work or not. Yes, sometimes the automation might wreck your settings but what if it is something subtle, like varying the speed of an LFO? At different times, different methods will apply.

Implementing just global patterns (ie. all patterns available to every generator) would just create confusion and mess.

Only if it is done poorly. There are many ways it could be done so that there was no more mess than we have now, and if you sometimes use a whole bank on an instrument, you already know how much of a mess that can be. Patterns could be organised into folders or automatically named or any number of other things. As long as we're able to access patterns as easily as we can now, I don't really see any problems. Of course, neither of those methods would be much use to me, because most of the time all my patterns are created in one or two instruments, then copied over to new ones as I add them. I'd be more likely to impose my own organisational structure on things, based on the way I work.

Take into consideration the events translation issue

Events are only an issue where you share a pattern and it has automation. If you don't share patterns with automation, you don't have an issue. More importantly, this is the same issue we have now, whether you use copy/paste, Clone or Merge, it is nothing new and won't be any more of a problem, just a little harder to ignore.

... if you change one pattern, it changes every and all patterns where such pattern is used. So the question is, would that be the case here?

Of course, it is one of the advantages of having the system.

I certainly wouldn't want to assign the pattern on another generator and modify it, only to discover that the original has changed as well.

Then just copy the pattern first, exactly as you would now if you wanted a variation on an existing pattern. This is a situation where global patterns won't have any benefit but it won't make anything harder, either. If part of the overhaul included a function to Make Unique, which is a meaningless concept with the current system, then it could make some stuff easier than it is now. It would work by making a duplicate of the pattern in the next available empty slot. A Duplicate button could do the same thing with the current system and would save us having to copy, find an empty slot and paste.

There would have to be a function that would truly copy the pattern

There already is, its called copy and paste.

Bones, I really hope you will understand this as a genuine attempt to understand the whole thing. You are debating that global patterns would solve issues we currently have now. I am trying to understand what issues you're referring to.

Mostly, it will make it much easier to experiment during the initial process, mostly in Pattern Mode. e.g. To try out 20 synths on a part until you find the right one, just as you do now by flicking through presets to find the right sound, or to see how layering two instruments might sound before you are at the stage where Clone or Merge might be handier. It would allow you to delete an instrument without losing its patterns, something I've tripped over in the past when I was in a hurry. It would also allow Orion to ship with some pre-defined patterns, ready to go, enriching a new user's first impression. Also, as I said above, it would allow me to better tailor things to suit my workflow and might do the same for you. e.g. Imagine if you could put your 64 drum patterns into a few sub-folders, so that you can better remember what each pattern is for. Currently, the only organisational tool you have is to go through and name them individually. Or you might prefer to organise patterns based on the arrangement. After all, it is only because we are forced to that we think of patterns as belonging to an instrument. In my case, the instrument I create a pattern with is almost never the one I end up using it with. If you think about it, it probably makes more sense to think of patterns as belonging to a part - bassline, rhythm, lead, etc - or to the arrangement - verse, chorus, etc - so you could organise them that way if you wished. I could sit here all day and think of uses but the rain has stopped and I'd rather be outside.

[Christophe]

i prefer to use receive midi from or copy paste and transpose method

Why? It is far less flexible, you're just used to all the restrictions it brings. Copy/paste removes automation, so you will always have to recreate that manually, and "Receive MIDI from..." takes over everything when you might want to use some patterns from the original instrument and some from the other. If anything, using these methods just shows how restrictive the current system is as they all have severe limitations that someone coming from another host application or hardware sequencer would see as ludicrous. And the advantages of the current system over this proposal is practically nothing at all, it just happens to be what you are used to, rather than what is best.

every software have limitations, but we love them because we choose orion !
and i choose orion because there is/was nothing hidden !
as you mentioned the current system lack of copy possibilities nothing else !
why do you prefer to change something that we are used to instead of coding copy paste automation ?
give me only one software where you can't copy paste the objects you have just created ?