Global Patterns

[bones]

We've been having a heated discussion for the past week or so on the beta forum. There is a lot of baggage there and I haven't been able to get my point across, so I thought I'd start with a clean slate here, to see what you guys think. It was something that was suggested on one of the KVR threads that got locked and addresses an issue that pops up now and then with new users.
Currently we have 64 patterns per instrument. It is a decent system but if you want to use a pattern with another instrument, it is not immediately obvious how you do that.

The suggestion is that instead o patterns per instrument, that all instruments share the same patterns. Obviously that would mean a lot more than 64 patterns but it would make it much easier to experiment with different instruments and parts. The biggest change would be to swap the A-H, 1-8 grid for some other kind of selector. An idea I had was this -

You would be able to go back/forward 1 pattern at a time, or 10 patterns with the FF/REW buttons (just like those buttons jump you back/forward 10 bars with the Transport controls). Clicking on the display would bring up a menu like you get for presets and double-clicking would bring up a window where you could enter an exact number. No pattern would be more than two or three clicks away.

Apart from that, the way you work would be pretty much the same. You'd find an empty pattern, set a length and put some notes and automation into it. The main difference would be that it wouldn't matter which instrument you used to create a pattern, it would be visible to every instrument, as they would all be accessing the same patterns. It would save you having to copy/paste patterns between instruments.

One issue that we have now is that when you copy a pattern and paste it into a different instrument, you lose all the automation on it. This happens because parameters don't match across instruments. e.g. Cutoff on Screamer is the 13th parameter but on Wasp it is the 23rd. If you can use any pattern with any instrument, there might need to be a better way to handle this than just erasing it. Here is one idea I had -

I've added one new drop-down menu so that instead of the automation being directly assigned to a parameter, it is assigned to a track (or lane or whatever you want to call it) and that track can be assigned to any parameter. So in the example of Screamer and Wasp, the automation would not be applied to cutoff, it would be applied to Track 1 and Track 1 would be assigned to Cutoff in each instrument. This could have real benefits. Imagine if Screamer and Wasp are playing the same pattern, which has automation in Track 1. You could easily assign Track 1 to Cutoff on both instruments, regardless the fact that Cutoff is the 13th parameter on one instrument and the 23rd on the other. Or you could assign it to two completely different parameters. e.g. Rage on Screamer and Cutoff on Wasp. It would make it very easy to experiment with all kinds of things you might not think of otherwise. Even if we keep the current patterns-per-generator system, adding this is a good idea that would allow you to paste patterns between instruments with automation intact.

Another advantage that Rich thought of is that Orion could ship with some pre-made patterns already created so that if you want to check out a new synth or something, you have some patterns you can use straight away. You could even create your own Default song pre-loaded with patterns for basic drum beats and stuff that will help you when you are trying out new ideas and you wouldn't be tied to Pro9 or DrumRack, you could use whichever you think is right for each session.

So, what are the downsides? The obvious one is that if you have one big set of patterns, it might get messy. There are plenty of ways to fix this. e.g. When you insert a new instrument, it automatically jumps to the first empty pattern or the next batch of 10 patterns or something, or maybe a pattern automatically gets named after the instrument you were using when you created it? A new shortcut to create a new pattern might help here, like CTRL+SHIFT+N, because a lot of the time you might want to use a pattern that already exists. There might be a way of organising patterns into folders that show up as sub-menus, like presets and plugins do. There might be a better design for the pattern selector that would make it easier. It would just be a matter of finding the solution that made it easiest for everyone.

So, have I missed anything? Are there problems I've not seen? More importantly, do you think it is a worthwhile idea?

[DivinEviL616]

I am liking the idea a lot. It would help streamline a lot of my initial work on a track. I have some ideas that I'm going to give them some more time in my head to make sure they'll fit properly.

Also in regards to Orion shipping with preset patterns, this would be nice, I already use the Randomize function for the purpose Richard suggested.

[kmatm]

I like the idea of having automation assigned to a 'track' which can then be assigned to any instruments' parameter.

The largest problem I see with the way I work is that I try to keep patterns for sections the same across all instruments, which makes it easy when in Song Mode to find which parts fit which the others.

eg: Intro is Pattern G, Section A is Pattern A, second section is Pattern B etc across all instruments... I then use A2 - 8 for variations and drum fills etc.

If patterns were shared you (or I) would no longer know which parts worked with what... A1 bass might work with B3 lead, but how would you keep track of this?

[iam7zark7]

If the patterns remain, as now, only viewable/manageable through the generator toolbar, then I can see it being both useful and not too confusing...with one exception. I will have to think about how I save each pattern.

If you mean that these patterns will be stored in some manageable directory (folder), it would become just another file-type to manage and obsess over. Too much housekeeping. If this is what you mean (and I think you mean the first), then why not consider my previous idea and save patterns as *.mid and manage them in your Midi folder with sub-directories for bass patterns, chord progressions, lead melodies, strings/pads patterns, etc. Put a selector in the toolbar tied to the Midi folder and name them whatever you like? Have buttons tied to sub-d's so that when enabled only patterns from the sub-d tied to the enabled button (i.e. bass) are shown for more focused lists. Here also, is the same exception as the first. I will have to name patterns.

Isn't *.mid the definition of global pattern?

-7zark7

[bones]

How does a .mid file store T-Slide data? I think converting to MIDI would require a more rigid format for all Orion's generators (but I could be wrong). I don't really like the idea of a new file type - as you say, too much housekeeping - just a different way of organising patterns to what we have now. i.e. Minimum disruption for maximum benefit. You also want to keep them with each song, so having them as discrete entities of their own would quickly become unmanageable as your repetoire grows.
I know what you are getting at with having to "think about how I save each pattern" but that is really just an adaptation you'd need to make, as patterns can get very messy now, too. i.e. At the end of the day B7 doesn't mean anything more than 017. Most of the work I do these days is on my band-mate's songs and sorting out what patterns are doing what sometimes does my head in but I don't see that it would be any worse this way than the current way.

The largest problem I see with the way I work is that I try to keep patterns for sections the same across all instruments, which makes it easy when in Song Mode to find which parts fit which the others.
eg: Intro is Pattern G, Section A is Pattern A, second section is Pattern B etc across all instruments... I then use A2 - 8 for variations and drum fills etc.
If patterns were shared you (or I) would no longer know which parts worked with what... A1 bass might work with B3 lead, but how would you keep track of this?

You could still do something similar. Let's assume patterns are numbered from 000. You could use tens and hundreds to create "sets" of patterns. e.g. You might put your drums in 000-099. Within that you might decide to put drums for your verses in numbers ending with 4 - 004, 014, 024, etc. - and patterns for the chorus in patterns ending in 5- 005, 015, 025, etc. Then you can put your basslines in patterns 100-199, again using numbers ending in 4 for verse and 5 for chorus. That is why I thought that having a button that jumps 10 patterns at a time could come in handy.
That is how Korg organise their preset banks in their big workstations. Even though I sold my Trinity in 2001, I can still tell you that a preset ending in 9 - 009, 019, etc. - is always a drum kit. Its very quick when you want to find a good sound to work from and it would work just as well here. It will also give you two extra patterns per block.
Of course, if you want to get really anal-retentive about it, you can always name your patterns as you go (but please don't ask me how, I've never used pattern names and I've forgotten how to do it).

[kmatm]

An extension of this idea is to use both the current pattern naming / numbering and this new idea, but 'lock' any patterns beginning with an alpha character (ie A, B, C..) to instruments, but make anything beginning with a numeric (ie 000) available to all instruments.

So the 'pattern selector' could still scroll through the numeric characters if you wanted to pull up a pattern that is available to all instruments. You could then select pattern B4 as you do now, but then trial pattern 032 from the numerical selector to grab a pattern you've made available to all instruments. Then change back to B4 if you needed.

That would keep everyone happy and not be a major workflow change.

[DivinEviL616]

Here is how I envision this concept.

Everything would stay roughly the same, each generator would still have a pattern selector however it would be modified to fit the changes. For example you could expand the amount of patterns store able in the banks and instead of the banks being labeled A, B, C, etc they could be labeled as to the type of patterns stored there. Bass, Lead, Sweep, Stab, Drums and so on and so forth. When you finish a pattern simply select a 'save' option that stores it into a specified bank. Perhaps a bank called 'unassigned' could be their default location to prevent the lose of unorganized patterns. (I could have convoluted things with that last part.)

Accessing the bank you choose from the patterns you have stored there and it gets placed into the piano roll. Perhaps options like 'Merge' could be incorporated to insert the pattern at the beginning or end of an existing one. The breeding functions for the generator presets could be included to encompass these patterns too. Simply use the same type of combination method on the midi notes their velocities octave placement and even length etc...

I also see a pattern selector on the transport that will allow you to select a generator off of the pattern in a small drop down menu making the generator open with that pattern already in the piano roll. I see them being saved internally within the song file having an option to export them like normal if need be. My logic tells me this would need a new preset type where the midi is stored along with the functions of T-Slid etc but you'd lose that data if exported.

This is a simplified version of what comes to my mind when I think of the concept. If I'm not calculating for something please let me know and I'll give it a rethink.


On a side note:
I may be alone in this, but what about an option to use a single piano roll to create a single pattern across several varying instances of a single generator. i.e. the way massive is handled by the dubstep artist in the creation of those bass drops that require vastly different presets and automation to be possible without a massive amount or sample slicing. In that single piano roll the user would select the presets intended for this function and each note would be assigned individually. I actually imagine this to be extremely complicated to set up and code so I'm only mentioning it for the sake of mentioning it.

[Lance]

I create the patterns for specific instruments and arrange them in the playlist.

I don't need a global pool. I could do that already by saving MIDIs, saving Templates, copy+pasting to a generator bank, saving Styles and reuse these, but I don't need these either. Very occasionally I saved a couple of MIDI back in the past for back-up and solving issues because of a problematic .sfs, recreating a song. I REALLY don't need a global pool and I think the whole concept harmful for Orion if it'l damage and or replace the current easy-to-use and logical pattern system, which was Orion's strongest area since day 1. No other DAW can offer better!

And it's very iportant a pattern should be there by default from the very first second of creating it, without any saving, sending, organizing hassle, where it is intended to be used.

Also it's very important for the workflow of arranging, song creation, that selecting and putting patterns into the playlist must be very fast. One click, and it's there. One mouse wheel movement there, and it's the desired next pattern on the track-arrangement of a specific instrument.

Seriously Bones, it's grey with miniaturized UI objects, it's having an awkward global pool pattern system, you said you have a license of it:

GO FRUITY LOOPS!

[Kriminal]

the idea itself is ok (you explained it better 8th time around ) but for the way i work, its not an improvement. I very rarely use the same notes on diff instruments, and alsmost never use the same automation twice

working with patterns pools and track (automation) pools is a bit like music by numbers, i prefer to experiment on the fly a bit more

its not much of an upheavel i guess to change to this way, i wont object too much, as long as old songs load and work exactly as they are meant to

my concern is keeping track of everything in the pools.

[Lance]

my concern is keeping track of everything in the pools.

Yes.

Can we put patterns into the Playlist so easily as right know, with global pool? A1 - A1 - A1 - then a small scroll up on the wheel of the mouse - A2. No!

Because the majority of the patterns will get in the way where we won't need them! We have to avoid an awful lot of patterns and finding needles in a stack just for inserting a desired pattern to create an 'arrangement pattern of patterns'.

The whole idea is unnecessary - as we can share patterns between generators very easily and in many ways already - and breaks apart Orion's strongest area and make it slower to work with.

Make that global pool as an optional tool alongside the current pattern system for those who think countless reusing of MIDI patterns is a good thing or let's forget about it!

[Teksonik]

We've been having a heated discussion for the past week or so on the beta forum. There is a lot of baggage there and I haven't been able to get my point across

I'm afraid your point holds no merit. You forgot to mention to long time users that the new system will require them to learn an entirely different workflow and that they'll be spending far more time with pattern housekeeping than they ever will with Copy/Paste or Clone To. You still haven't addressed how older song's patterns will be loaded and organized. You still haven't addressed how global patterns will be organized and for large projects it will just be a mess....all for something that brings nothing new to the table. Not to mention the time it would take to code such changes....time that could be better spent on adding something new to Orion.

If by 'too much baggage" on the Beta forum you mean people are disagreeing with your idea then yes but I'm not sure anyone who made the following statement in in any position to argue for the complete change of Orion's workflow......

WTF!?! What "Clone Track to" dialogue? I had no idea any such ting existed and I sure as hell can't find it anywhere. Did I sleep through a beta cycle or something?

Sorry I still think Global Patterns are a bad idea since they break Orion's current Pattern per Generator workflow. We can only hope that Rich thinks it through and decides against such a change to the current workflow of Orion. And in the end if he does change Orion to be more like Fruity Loops then we at least have the option of not "upgrading" to the new version......

-1 for Global Patterns

[Teksonik]

Here's an example....Say I load up the fifth instrument in a song. Now I have to remember which patterns the first four instruments used and which patterns are still available to this new instrument. Then when I go to the Playlist I have to remember what patterns were written specifically for that instrument....Now figure how that will be for 10 instruments or more....an organizational mess. And in the end how many times do you really use the same pattern for more than one instrument? I frequently layer two or more synths for a Bassline or a Pad part but that's already easily accomplished with Clone To..... Do you really need to have a Hi Hat pattern available for a Bass Synth or Lead Synth? How many times are you going to use a Kick Drum pattern on a Piano part? Or a Melody line in a Drum Synth? Is pattern 87 a Bass drum pattern or a Bass Guitar pattern? Which patterns does instrument number 8 use? Think of how patterns will translate in the Playlist. It will be a hodge podge of unrelated numbers or you'll be spending all day renaming patterns so they make sense. With Orion's current Pattern Per Generator I know that the patterns I have created for Albino that's set to a bass patch will be bass patterns..the patterns I've created for Pro9 will be drum patterns etc etc....if I want to use those Pro9 patterns in another Drum Synth I simply Clone To and if I don't want to keep the Pro9 I simply delete it..everything that Global Patterns can do already without the horrid mess of a jumble of unrelated patterns......

[Teksonik]

Make that global pool as an optional tool alongside the current pattern system for those who think countless reusing of MIDI patterns is a good thing or let's forget about it!

We don't often agree Lance but in this case I agree with you 100%..........

[Mark]

Make that global pool as an optional tool alongside the current pattern system for those who think countless reusing of MIDI patterns is a good thing or let's forget about it!

We don't often agree Lance but in this case I agree with you 100%..........

My interpretation, which got lost, was to have it as a layer above (and separable) from the existing system. I think bones is actually thinking along similar lines especially when he states that making a new pattern in the piano roll automatically adds that pattern to the global pool. The process of making patterns is still the same, you just have a central repository on top for easy access of existing patterns by other generators.

I'll try to find some time to go in to more detail a bit later. I'm just in between teaching students (and colleagues) today so I'm short on time to do this now.

[Lance]

Regarding pattern systems:

Orion's current and traditional pattern system which more logical and very suitable for fast working is superior to FL Studio's.

BUT, by the destroying of this system and replacing it with a global pool, Orion's system will be even more awkward and INFERIOR to FL Studio's!

WHY? Because at least FL Studio's single pattern can be a logically working full song-part and also you can work in FL clip-based too already in the traditional way of the sequencers.

Probably I won't be keeping Orion as my main sequencer if this global madness happen and I can't use Orion as fastly and logically as now. I was a loyal user of Orion since V3, I bought it as expensive boxed product and paid upgrade fees for it. I wouldn't want to ditch it, I hope it'll have strong areas for which it'll be worthy to ReWire to or fire-up for special tasks, but nowadays I'm searching for my next main tool, as instead of addressing those areas on which Orion is limiting, I fear it will be getting worse on those areas where it was strong.

So my wish for now: ReWire 64-bit support!