Forum to discuss all matters relating to the MPC1000 and MPC2500 operating systems created by 'JJ' (all versions).

By stale bread Thu Nov 23, 2006 10:34 pm
actualy the way it is now is more 'un-intuitive', having to go into grid edit mode or where ever else to do something as simple as have each track loop on diff amount of bars..... that's actualy more steps then necessary to do a simple thing.
User avatar

By Antonym Thu Nov 23, 2006 10:39 pm
right, but it's a total reinterpretation of the given seq file. which is a lot of work, and there are many other things that could be done without as much rewriting. not that it isn't a great idea.

however, remember on jj's page - FUTURE included simultaneous sequence, which could be used the same way.

By sleepersriddle Thu Nov 23, 2006 11:00 pm
tombola wrote:I'd really like this too. Copying two bars four times is a faff, and if you change the loop you have to do it again.

Another similar idea: If you change the sequence length from 2 bars to (say) 8 bars, there's an option to automatically loop all the content in those two bars across the 8 bars.

So you can quickly write a two bar drum pattern, then whizz it across 8 bars and put a fill at the end.

tom


Yes!

That is logical and would save time.
User avatar

By melton Thu Nov 23, 2006 11:01 pm
stale bread wrote:you can make some insane polyrhythms like this.


that is the truth!
I made some stuff on with my rm1x that used different length tracks, and the way it would evolve and still sound right... totally rhythmic, but hard to tell where it loops... so if you have a bass drum pattern that's 4 bars and a 5 bar pattern for your snare the sequence loop is 20 bars long.
On a practical tip, it's nice for building a sequence from 2 bars for drums to 16 for melody... but I agree with Ant that it's probably too different from the existing MPC structure to implement... Not that it wouldn't be wicked to have.

I think a Double Sequence button from the main section would probably be easy to implement, and serve a similiar purpose.

By skamgdi Sun Nov 26, 2006 8:41 pm
i think this would be a great feature also i understand where they are coming from saying you COULD just do this or that but who wants to when it could be so much easier why make 3 steps while if this was added you would need none..... and like others said you could come up with some really cool sounding tracks with out all the hastle... mabye they are just using their mpc solo but me i use my motif es, karma ,access virus c , and my mpc so i have alot cut out for me in the first place navigating all my equip then to have a simple loop change done i need to spend time on the mpc reprogramming and making new seq's to get the drum change i want or to make a stutter step come in ever 4th bar or my 4th loop.... pretty damn annoying this wqould be hellofa feature that would make workflow much better and if im not mistaken this is one of the reasons (besides new features and shyte that was already supposed to be there but wasnt) jj created this os

By open_fource Sun Nov 26, 2006 11:54 pm
simultaneous any length sequences with auto-looping. yum. go even further and have a pads to Seq Mute like Track Mute is now. I think this is thanks to FruityLoops' "patterns" modifying my method of building tracks. I want to work on Sequences like "chorus drums" seperate from "chorus vocals" yet play them back together at will.
User avatar

By Antonym Mon Nov 27, 2006 4:08 am
like i say, this proposes a pretty severe modification of the SEQUENCE file architecture, one that might cause a huge number of unforseen bugs, etc.

at this point, though, it looks like simultaneous sequence would fill this gap VERY nicely.

By stale bread Mon Nov 27, 2006 9:45 am
could you explain simoutaneous sequence and how it works

By stale bread Mon Nov 27, 2006 9:47 am
oh yeah and Antonym why do you think it takes such a modification, whats the background on that and thanks for the insights
User avatar

By Antonym Mon Nov 27, 2006 3:28 pm
could you explain simoutaneous sequence and how it works


well, apparently the 3000 could do this. essentially, it's exactly what it sounds like. you make 2 sequences and play em at the same time. since you could make different seqs different track lengths, you could program said seqs according to what many have expressed as wishes.

why do you think it takes such a modification, whats the background on that and thanks for the insights


as of now, changing bars of a pattern you're making on the mpc is done to the sequence, not the track. the sequence controls every track. also, think about this - you save and load sequences, all or one. you don't save or load tracks (although i think it'd be a great idea to be able to do so, it seems like a lot of work).

since all the mpc code is built upon interrelated file types (pgm, seq, prj, ini, etc) adding one or changing one could also change the rest, sometimes for worse (bugs).

the backgroudn on these cautionary words are from jj's faq - "you have to keep in mind the compatability of" etc etc etc.

i'm no coder, so it very well may be an easy thing to do. however, from what i DO know, it doesn't seeem like it could be.

my thoughts. i think it's a good idea, and more than anything i like that people are bringing in "best of" features from different machines. that turns our 1000 into a little frankenstein. so i support it and i def wouldn't block this from going through, but from what little i know i have doubts as to its ease.

for example - jj's been working on this grid qlink edit for a while now. luckily this is a feature i am really excited about. however, what if we were told that he would work on diff. track lengths and a way to load individual tracks instead of whole seqs - but that he wouldn't finish til say next june?
User avatar

By Antonym Mon Nov 27, 2006 3:30 pm
ALSO, what would this do to compatability with other non jenius mpcs?

granted, i don't do much sharing of my projects, but what about those who use multiple mpcs or are part of a production team that consists of a cracked out 1000 on jenius pills and a good old 2000xl?

i forsee 2 things: one, said projects don't load into the older mpcs. that's the peaceful option. 2, the jenius users unite into some really ugly kind of elitist group and hold an mpc burning of all older species...

By AFF Mon Nov 27, 2006 4:13 pm
i'd say 1k files would not be backwards/forwards compatible if this was implemented.

however, ableton live use this diff length seq system i believe. and personally if it wasn't such a problem to do i'd love it.

By stale bread Mon Nov 27, 2006 10:43 pm
i see where you're coming from...

imho it would be nice if all the mpcs were backwards/forwards compatible with each other but... and this is just me personaly .... I feel thats a bit of a utopian outlook. I kind of live my everyday life with that outlook so i'm not against it its just that I only have 1 mpc, the 1000 and before i worry about being compatible with other mpcs i'd preffer to get my own songwriting needs worked out if possible. the mpc 1000 is cheap and an unbelievable deal with jj onboard so i'd rather others go out and buy a 1000 if it's a choice between that and key features, i choose the features.
of course I wouldn't want jj to stop implementing any features they're currently implementing or that others wished for to do my wish instead. but this feature is extremely useful, and it exist in every other sequencer just about for that reason, plus it would help us on the sequencing and sampling too. imagine patched phrases with diff track lengths running side by side. I know you're not blocking it, just wanna say I understand where you're coming from.
User avatar

By Antonym Mon Nov 27, 2006 10:53 pm
definitely, all those points you've listed are dead on.

i'm not expecting compatability - i mean, shoot, where do you think your TRACK qlink record motions go when you load it onto a 1k which isn't running the jenius os? they go down the tube. i never will go back from the jj os on my 1k, and i doubt i'll ever move away from my 1k (why do it? you have your whole life ahead of you). the biggest concern is file architecture, but i know so little of that it's barely worth me encouraging repetitive stress on my fingers typing about it haha