Is it time for OS3?

Imo OS2XL is pretty much done (for what I use it for anyway), as much as I love new features i think JJ should spend some time optimizing the code to help the cpu and call it a day for OS2XL. I'm seeing a split in the JJ forum where some of us want the features for external control for and from the mpc while others are saying that they'll never use the mpc that way, it's just not in our work flow. I feel that JJ has been putting in a lot of work on XL and seems like he still has a lot more planned, maybe its time for OS3? The features he's been adding lately are so far from what some of us want and at the same time they are features that some of us have been asking for for a long time, they are pretty big additions to the OS so why not have JJ get paid for his hard work and create a new OS geared towards these new features for a different type of work flow.

It just seems like JJ might try doing way to much to the point that some people might start experiencing issues all because features were added that they didn't request, never use and could care less about. JJ has added features for live use and external control which is great but he could just make whole a new OS that focus on that type of workflow and really go all the way with the features and leave OS2XL for more studio use with just some live and external control features. Everytime JJ has added major changes/features to the OS he's put out a new OS so why not now? Having said all this, if JJ can do it everything he wants to do in OS2XL without causing any problems then that's great and if he wants to put all this work in and do it for free then that's cool too to but sometimes just because you can do something doesn't mean that you should. What does everyone think?

My point of view is each time there's a new OS or a very big update you have to pay a certain amount of money.
A newcomer has to pay "US$ 123.00." to get the latest JJ OS. I'm not sure if you'd have to add 50$ to that you won't reach to a psychologic price (a third party os that costs a lot compared to the value of the mpc1000)

In my opinion it would be better to improve existing feature that are not yet fully optimized.

While I'd hate to see a split in the way you're mentioning... I'd would like to see at some point an OS3 drop so that we can see OS2XL become more stable/bug free. At some point you need to say these are the features you get for this version and push on ahead. Personally I'd hate to see features dropped in OS3 in favor for studio work, but I think some refinement can be done that probably shouldn't occur in OS2XL.

something like plugins would be cool, so that you can "install" the features you like.
love to see a monome or tenori on style sequencer

ontherun wrote:something like plugins would be cool, so that you can "install" the features you like.
love to see a monome or tenori on style sequencer

Genoqs Octopus? Obviously asking too much, but we can dream right?
http://www.soundonsound.com/sos/mar07/articles/octopus.htm

JJ os has always been about improving the worflow.
Insofar as timing and stability are preserved I think there's no reason to complain about new features.

hm. i say let jj do what he wants. we can all dream and we all have an idea of what's most important, what's the best direction for the OS, etc.

in os2xl, we all have more than enough to make our music in a wide variety of styles and workflows - far beyond what we thought possible with these two mpcs. added "offline" functions that don't compromise either the stability or performance of the MPC should just be of no concern to those who do not use them.

one trend i've noticed (and been a part of in the past) in quickly-developing, user-friendly program development user groups is "discussionitis" which is exactly what it sounds like - over discussion of possible development direction, "groundbreaking" potential feature possibilities, remove-this-feature-to-make-room-for-another, "who needs whatsits," etc etc. this is not to say that some of the FR ideas i've read here aren't brilliant, but when the signal to noise ratio gets too high, developers ears get drowned. i'm currently watching this happen in the Reaper development community right now.

i don't think there's any way around this, but it's definitely something to be aware of.

edit - i'd also like to say that as an extremely novice programmer myself, it really help to think of feature requests that are small, simple and extremely easy to implement. for example - a long time ago now, jj added "TO NEXT NOTE" in the DURATION section of SEQUENCE EDIT. this function extends the note durations in your track to the next note, so that if you're using a chopped sample w/ loop points, you can emulate a MONO pgm w/out losing your pad release states. adding this FR was a piece of cake - simple math, really - yet it had a huge impact on my personal workflow. tailoring the FR around the existing functionality of the OS is really what got it implemented, if you understand me.

It's all about tight sequencing for me. I use my mpc to sequence and control everything. If that sequencing ever gets fcuked up then I'm screwed. I completely disowned my mpc when I found the timing bug that JJ introduced in JJOSXLv1.38. Luckily he realised the bug and fixed it in v2.01, but it was hella long time before he fixed it. To me, that was like breaking a leg and not going to the doctors till a week later, even though you couldn't walk.
I just hope JJ keeps his focus on ensuring the tightness of the the mpc's sequencing above all else. That is, ofc, a personal wish.

I'm new to JJos, but goddamn its worth the money. I can see its a balancing act between stability and features sure, but also i see requests of the jjos and wonder if the ability is there in JJos and people dont see it?? Well anyways, I can still make it hang and crash but Only when im doing three things at once so no big deal. Anything is better than Akai Os, sorry akai.

Nym wrote:hm. i say let jj do what he wants. we can all dream and we all have an idea of what's most important, what's the best direction for the OS, etc.

in os2xl, we all have more than enough to make our music in a wide variety of styles and workflows - far beyond what we thought possible with these two mpcs. added "offline" functions that don't compromise either the stability or performance of the MPC should just be of no concern to those who do not use them.

one trend i've noticed (and been a part of in the past) in quickly-developing, user-friendly program development user groups is "discussionitis" which is exactly what it sounds like - over discussion of possible development direction, "groundbreaking" potential feature possibilities, remove-this-feature-to-make-room-for-another, "who needs whatsits," etc etc. this is not to say that some of the FR ideas i've read here aren't brilliant, but when the signal to noise ratio gets too high, developers ears get drowned. i'm currently watching this happen in the Reaper development community right now.

i don't think there's any way around this, but it's definitely something to be aware of.

edit - i'd also like to say that as an extremely novice programmer myself, it really help to think of feature requests that are small, simple and extremely easy to implement. for example - a long time ago now, jj added "TO NEXT NOTE" in the DURATION section of SEQUENCE EDIT. this function extends the note durations in your track to the next note, so that if you're using a chopped sample w/ loop points, you can emulate a MONO pgm w/out losing your pad release states. adding this FR was a piece of cake - simple math, really - yet it had a huge impact on my personal workflow. tailoring the FR around the existing functionality of the OS is really what got it implemented, if you understand me.

Its called low hanging fruit. I like to call it ROI programming. You pick the features to add based on whats the easiest to implement and that you will get the most bang for your buck (spending the least amount of effort for the greatest gain). The problem is that its not always obvious. and its definately not always obvious to the users. JJ is the guy familiar with the code, so he knows the ins and outs, whsats easy, whats a pain, whats agood idea, and whats bad. All we can really do is let him know what we would like, its up to him to pick the low hanging fruit based on our feedback and his knowledge of the code.

I say let JJ go the directioin he wants. We do need to keep telling him what we want. I agree we have to be careful of signal to noise ratio, but at the same time, saying nothing will get us no where. I think jj has shown that he is very good at making decisions and deciding what feautures to add based on stability, pleasing the users, and gains/improvements for the workflow as a whole. I say trust JJ! thats why he is the expert - part of being a good developer/programmer are those exact decicsions of knowing what the users is asking, and what the user actually needs, and what you should actually give the user.

On another note, i dont like the idea of forking the OS. I agree it would be nice to get OS2xl stable as possible at its current state, but I dont think forking OS at any point should be an option (as in, one OS for one workflow, one OS for another workflow). It should always be a continuation and improvement of 1 OS.

And with feature additions, there are always going to be bugs. infact, you can always expect bugs, its part of the game. Even if you think you have the code perfect, there is always something you didnt think of or a way someone uses the OS you didnt expect or anticipate. Ironing out bugs takes time. So i say its a bad idea to hault all feature request just to iron out bugs because bugs will never end. i am not to say bug fixes shouldn't be a priority, but they should not stop positive enhancements.

Finally, JJ has a view of the entire picture (the entire OS and where he sees it going). To say that one feature addition is targeted to one type of workflow is ridiculous. There is so much under the hood we have no clue about. Just because he adds 1 feature, does not mean it does not impact or tie into another feature. infact, the addtion of one feature may add a stepping stone to one thats completely unrelated. you can not take a piecemeal view on his choices for the OS.

edit - I do think that performance of the OS is a legitamit concern. But that does not neccesarily mean it can be lumped in with "Bug Fixes" or directly corelated with a feature addition as it may go deeper. But, if you do experience a bug, a problem, slowness, it needs to be discussed and JJ needs to know about it, including specific details of when the problem occurs. You can not just say "its slow" because that means nothing, its not specific enough......as everyone uses the machine differantly. its safe to say that its probably slow for some poeple, and not for others, depends on what you are specifically doing, so you need to be specific if you want things to be a priority.

vagueness = nothing will be done about it. when fixing a bug, usually the first step is to try and recreate the bug so you can see what conditions cause the bug and help narrow down where you need to look to fix the bug.

not aiming this post at anyone if it comes off harsh, just saying.


my 2 cents
peace

le rat wrote:In my opinion it would be better to improve existing feature that are not yet fully optimized.

Exactly... Do we need a new os version every few months or what? I would rather see the actual os to be optimized and tweaked instead of releasing new one... It makes really no sense...
The second thing is that at least 9 of 10 of overall feature requests are absolutely unusable and have nothing to do with the main idea of the mpc and only the requester of that feature will use it...
And the last thing - this thread should be locked...-its one of the million others where people will post their crazy requests and I don't think we need another post like this....

There was already a new version. Its called os2xl v2. To me it seems that this version is about making the mpc a fully functional multitimbral sound module. I have no plans right now to use it that way, but never know what the future holds.

mp3 wrote:To me it seems that this version is about making the mpc a fully functional multitimbral sound module.

Personally, if I wanted that functionality I'd use a rack sampler.

look, both these last points are valid, - the mpc has often been laughed at by some users - because it cant do basic sampler things like we expect in this world of midi and studio integration, but it hasnt detracted from the machine, its been truly enhanced in my opinion.

as long as there arent any removal of bona fide useful functions to make 'space' for less useful ones, thats the key to it for me.

and as long as there's room for improvement, ie: actual code space and ideas to add, then yeah JJ can keep going as far as i'm concerned.

the only caution i can add is that in the OS2 days before XL, there were quite a few stumbling blocks that led JJ to remove functional items much valued by users in OS2, in order to pursue ideas on the XL framework, that was a sore loss to many of us, and i'd hate to see XL suffer in the same way, but this is very tricky for JJ , cos we all have different priorities. JJ included.

jimmie wrote:

mp3 wrote:To me it seems that this version is about making the mpc a fully functional multitimbral sound module.

Personally, if I wanted that functionality I'd use a rack sampler.

Sure, but there are benefits here. For one, not having to buy/upgrade/learn a new (old) piece of gear, and not having to worry about storage, sample transfer, etc. Second, having access to the MPC's interface; its easily the best/fastest sample chopping and mapping interface of all time. Third, using the pads/q-links as a MIDI controller. Fourth, having instant access to your hundreds or thousands of existing samples, chops, mapped kits, programs, etc.

I'm not interested in bypassing the sequencer at all (at this point), but its pretty cool to know its possible.