OS 1.70 coming soon.

Hey why all the yelling? Go grab a beer and chill out man.

Kalei

OH CAPPS Sorry my work requires that I type in all caps sometimes and in switching between the forum and work I forget to turn it off

So anyone knows a date yet for the next release? Or beta release?

btw, a happy newyear and a funky eastern to yall MPC heads!

Intellisample as I remember it meant you were able to sample several samples batch-style and programs would be automade and probably other stuff i cant remember. In what way is intellisample implemented in the 4k now?

Kalei

As Sean wrote on the DPS world forum or MPC world forum, whatever it's called on July 18 2004



"Intellisample" was not taken out of the features list.
It is already implemented, but it is different from what you are suggesting.
In the MPC4000, "Intellisample" means:
* Auto-Normalize option
* Ability to build programs by assigning new samples to Pads while sampling (ADD PGM option)
* Ability to add FX while sampling (Q-FX option)




Adrian
FWTX

AWW_NAWW wrote:I have never complained about a peice of gear in my life ...well maybe my vs-1880 because I didnt know how to get the panning automation to work but that was a user issue not a product issue.

Complaining is one thing, justified complaining another.. just because there's a thereotical workaround for everything, doesn't mean it's never right to complain.

In general the 4K is a beatufiful piece of equipment and really nice to use. This doesn't change the fact that it has a few idiotically designed "features", which simply doesn't make any sense. Having paid for it in the first place, I think people at least have the right to acknowledge what they feel could have been made better.

It's a bit dissapointing for any piece of "professional" equipment to still lack features announced several years ago. Like the mysterious .PRJ file, I simply dislike they way you handle projects right now. And how hard would it have been to implement? It's no "workaround" to do as we do now, quite frankly it's the only way you can use it. Still love it though.

pUs wrote:

AWW_NAWW wrote:It's a bit dissapointing for a piece of professional equipment to still lack features announced several years ago. Like the mysterious .PRJ file, I simply dislike they way you handle projects right now. And how hard would it have been to implement? It's no "workaround" to do as we do now, quite frankly it's the only way you can use it. Still love it though.

Why do you need .PRJ files while you have the folder load feature?

Rob wrote:

pUs wrote:

AWW_NAWW wrote:It's a bit dissapointing for a piece of professional equipment to still lack features announced several years ago. Like the mysterious .PRJ file, I simply dislike they way you handle projects right now. And how hard would it have been to implement? It's no "workaround" to do as we do now, quite frankly it's the only way you can use it. Still love it though.

Why do you need .PRJ files while you have the folder load feature?

Because I don't enjoy the concept of being forced to fill upp the hard drive with stacks of redundant programs. If I have a bass program that I'd like to use in a few beats, I'd like to point to that specific program in my library of programs. Quite simply, I don't like being forced to have everything in one folder for each project.

And sure, if I really want to I can save into the program folder which I use for a specific project. But I want to have that choice myself.

pUs wrote:

Rob wrote:

pUs wrote:

AWW_NAWW wrote:Because I don't enjoy the concept of being forced to fill upp the hard drive with stacks of redundant programs. If I have a bass program that I'd like to use in a few beats, I'd like to point to that specific program in my library of programs.

And sure, if I really want to I can save into the program folder which I use for a specific project. But I want to have that choice myself.

I see. There was a lengthy thread devoted to this subject a couple of months ago on the Akai mail list. Steve from Hollow Sun explained why it is very unlikely that Akai will ever introduce the feature where a PROGRAM is referring to samples stored in another folder. It's not easy to deal with that, if the samples were moved to another place. Without knowing, people will break old songs, just by 'cleaning up' or 'regrouping' their samples.

But maybe what you're asking is a MULTI that refers to PROGRAMs stored in another folder, while the associated samples are stored in the folder where the PROGRAM is stored. A project file could be a combination of a couple of those MULTIs and the sequence data.

But the same problem arises here: if you move a program+samples to some other place, or rename one of the directories that leads to that program, you'll be breaking existing songs that refer to that material. Think about it. Most people don't understand what happened and will start complaining like hell. MPC is c.r.a.p! I LOST my stuff! Etc, etc.

Of course the power users know what they're doing, and could probably handle the 'remote' data concept reasonably well, but I'm afraid that 90% of the users can't.

Personally I'm happy with the choice they made. There's tons of data redundancy on my disk, but at least I'm dead sure that all the data I need for a given song is right there, in it's own folder, and I never have to be afraid that the song would get corrupted in the future by some cleanup action I'll do in a year from now or so.

Rob wrote:But the same problem arises here: if you move a program+samples to some other place, or rename one of the directories that leads to that program, you'll be breaking existing songs that refer to that material. Think about it. Most people don't understand what happened and will start complaining like hell. MPC is c.r.a.p! I LOST my stuff! Etc, etc.

I know, I remember the discussion from the mailing list.

But no, it won't have to be a problem. If you had, for instance, some kind of program 'library' where you registrered like your 'favorite' or 'most used' programs which you're likely to use again (heck, call them presets to make it more understandable), each registered program could be given some kind of ID and the program itself + its samples could simply be given a read-only attribute. If the user tries to change anything in such a program you'll just be prompted like in Windows.

And the multi would then just point to program ID 123. Plus would only have the option of doing this on 'registered' programs - makes it easier to implement such a function.

Believe me, it is not a hard thing to do. And the problem with overwriting will always exist as long as we have the option to save our work. You can easily delete something accidentally or modify something accidently even if you have the stuff in one folder. I can't accept that as an argument; if that's the case then why be allowed to change any files at all. I mean you could damage stuff.

I understand the library concept, but don't you think it's all getting a bit too much computer-like? The complexity of it all doesn't really fit in the relatively simple MPC concept, imo. One of it's attractive features.

But even if they'd implement that library. What if I remove one of the preset programs? Or update it? Or re-use the ID for another preset program? Same problem again, it would invalidate the songs that depend on it.

And yes, as long as I can write the HD, I can damage my songs. But the point is that with using indirect structures like remote programs/samples or library presets, it's not OBVIOUS that you're breaking existing songs. 'Hey, I just updated that preset, and guess what!' The problem with indirect structures is that after a while you don't remember what song depends on what data, somewhere on the disk. So the chance a song gets corrupted after a while is sky high. And remember, many users hardly know what a program is!

Corrupting your local data is possible too, of course, but while you're writing your data back to your song's local directory you KNOW what you're doing. With remote data, you're really unaware of the results, there's no good control. That's the real problem.

No no, I think that having all data used in a song stored in a local directory is almost perfect. There's redundancy yes, but who cares. HD's are soooo large nowadays. And if I want a set of preset programs, I just load them from a central place (e.g. another partition on my large HD), together with the samples. Once in the song, I'm free to modify the program and samples, because it's unique for this song now.

Rob wrote:I understand the library concept, but don't you think it's all getting a bit too much computer-like? The complexity of it all doesn't really fit in the relatively simple MPC concept, imo. One of it's attractive features.

You might have misunderstood me; You wouldn't HAVE to use this library if you think it would get 'complicated'. You could go on as today. What's the problem then? Face it. It's "computer-like" with a nice 40 gb IDE hard-drive, you can't get away from some realities, like a file system, problems which occur when over-writing etc.

But even if they'd implement that library. What if I remove one of the preset programs? Or update it?

You wouldn't be able do that, didn't you see what I wrote about read-only attributes?

Or re-use the ID for another preset program?

No, the system would adress each registered program a unique ID's, it's not something you would see as a user, nor could you "re-use" ID's. Irrelevant question.

Same problem again, it would invalidate the songs that depend on it.

NO, the registered program would be read-only.

And yes, as long as I can write the HD, I can damage my songs. But the point is that with using indirect structures like remote programs/samples or library presets, it's not OBVIOUS that you're breaking existing songs. 'Hey, I just updated that preset, and guess what!'

For the last time, read-only flags. Still not getting it?

The problem with indirect structures is that after a while you don't remember what song depends on what data, somewhere on the disk. So the chance a song gets corrupted after a while is sky high. And remember, many users hardly know what a program is!

Which of course you won't have to remember. The Multi remembers it for you, with the help of the ID's I described.

No no, I think that having all data used in a song stored in a local directory is almost perfect. There's redundancy yes, but who cares. HD's are soooo large nowadays.

So let me get this straight. You don't want any added flexibility whatsoever, even if it means you could still keep on doing things exactly as you do right now? Jesus.

We're talking about an OPTIONAL way to handle programs together with multis, not about changing the workflow. Different users have different needs.

Sure I want added flexibility. But personally, I wouldn't use the library presets. And I don't think it's possible to keep everything read-only. There will be a point where you want to add new presets while the disk is full, meaning that you have to remove old ones. There will be a moment where you added a new preset and realized that it's broken somehow and needs tweaking, or replacing.

I just don't think the added complexity, and the unreliability of songs that depend on external structures are a bonus for the mpc. But that's just me. Who cares what I think.

Rob wrote: And I don't think it's possible to keep everything read-only.

Sure it is. Just have a separate function/screen/page in the OS where you have an overview of all your presets and where you can manage them. Only there you could remove presets or remove their read-only attribute.

pUs wrote:

Rob wrote: And I don't think it's possible to keep everything read-only.

Sure it is. Just have a separate function/screen/page in the OS where you have an overview of all your presets and where you can manage them. Only there you could remove presets or remove their read-only attribute.

Right, and the moment you remove/change a preset, you probably break one or more songs that depend on it, without knowing, or while thinking it's okay since no song is using that preset. Of course you forgot that one song you created many months ago.

You could come up with this solution: before removing/updating a preset program in the library, have the OS make a list of all songs that depend on it. Could be done, but it would mean that the whole harddisk would have to be scanned (slow), or that a list of dependent songs have to be kept in the library, per preset. The latter option however is not easy to maintain, because everytime you change a multi, delete a program, or delete a file or folder from disk, the data to be deleted has to be examined before it is deleted, in order to update the list of dependent songs in the library.

The first option (scanning the disk for dependent songs) seems more reliable, but it could take a long time to scan a large disk, and what happens with songs that are backed up on cdrom or on the computer? These are not 'seen' in the scan, and hence a preset program is 'freed' while songs still depend on it.

All in all it's getting complex. And all of this is a non-issue when using the current approach, by making local copies of the needed data.

Rob wrote:
You could come up with this solution: before removing/updating a preset program in the library, have the OS make a list of all songs that depend on it. Could be done, but it would mean that the whole harddisk would have to be scanned (slow), or that a list of dependent songs have to be kept in the library, per preset. The latter option however is not easy to maintain, because everytime you change a multi, delete a program, or delete a file or folder from disk, the data to be deleted has to be examined before it is deleted, in order to update the list of dependent songs in the library.

Not neccesarily so. You could have the system automatically maintaining a hidden table consisting of all "preset"-programs associated to any multi. As soon as you save or update any given multi, any references in the table gets updated. If the multi points to three different presets - these three preset programs all end up in the reference table.

The system could then just access this table if you try to update any given program. If it ain't listed - go ahead, you can update. No need to scan the whole hard drive.

It might not be a neccesary feature - that's a matter of opinion - but believe me, it's not hard a one to actually implement. I'd dare say so without even knowing the exact architecture of the OS itself.