No, not exactly. Saving a program, at any point during your session, will first overwrite all the files in the program folder, and then when you resave the project, inevitably it too will overwrite all the files in the project folder. It doesn’t matter what order you do that in, or whether you change any other parameters first.
The only way to avoid this behaviour altogether, is to never resave your programs: i.e. build your program in a single session, save it once; then any changes that you make from there, save only the project, not the program.
Of course, this makes for a very isolated workflow, and doesn’t accommodate everyone’s needs (certainly not mine); but it will keep your files safe, pending a fix.
First of all, I don’t “believe” file degradation is happening—it’s happening! There’s no question about it, and I’m in the process of demonstrating this to whom it matters, so we can move on from the ambiguity of it all.
Secondly, data corruption happens more often than you think; especially in systems wherein data is getting written and rewritten constantly. Most of the time, however, we either notice it straight away (i.e. a file won’t open, a download fails, a program crashes, etc.), or it’s inconsequential and otherwise too insignificant to notice at all. That said, most programs that are designed to manage ongoing projects, wherein many incremental changes are necessary and continuously resaved (i.e. pick your DAW, Photoshop, video editing suites, spreadsheets, etc.), avoid potential corruption by reading files directly from disk, creating “layers”, and essentially working, non-destructively, from the original file, until such time as you choose to export a final copy. At which point, you’re making a new and autonomous file (ideally).
We do see this safety net built into the MPC software: i.e. when you save a project, without first saving a program, the project only saves the incremental changes that have been made to parameter data since the last save; and it otherwise leaves the samples in the sample pool untouched. This system exists for a reason! However, the problem at hand (call it a bug if you want) is that program files are not handled this way. Instead, when you save a program, it recollects and overwrites all the sample files destructively. So, if any corruption occurs, however small, you’re now stuck with it; and that corruption will be carried forward and compounded with every new save.
The bigger issue is that, every time a program has been changed and resaved, the project is now compelled to recollect and overwrite all those files, again, as well. It’s gratuitous and unnecessary and a recipe for disaster in the long run.
Anyway, it is a thing, it is happening, it is a problem, I have proven it where it counts, and I am not going to reiterate or reword any of this again.
Thanks again, everyone, for your deductive reasoning and constructive conversation… Much appreciated!
That could be quite nice. I saw someone on NI forums made a stand they could slot the laptop underneath which was pretty cool. There’s another one on there where a guy actually built a computer into his mk2
I want to show you guys my new project. It is another fully standalone maschine. Inside It has i5 processor, 4GB ram, ESI MAYA audio interface,128GB SSD drive. It also has a battery, so I can work few hours without cables. On the back it has two USB 2.0 ports, HDMI out, audio IN/OUT, headphone out with potentiometer, power switch and power socket for charging. Back plate was made form thick aluminium sheet (cut by CNC).
I’m Dan, Product Manager for Akai, and I was sent here from a gearslutz user. I’m super new here, so I didn’t see a way to send a PM. is it possible you could contact me directly? my email is firstname.lastname@example.org. thanks!
Dan man! Welcome to the forum, I’m happy to see you around these parts. I hope you’ll find it more enjoyable than Gearslutz, I know I do haha…
I know this is not exactly the place for it, but there are some things I would like to see implemented on the Live that would completely change the game for me and, I’m sure, many others. Especially the Elektron wierdos
1 - Modulation! An extensive mod matrix would be absolutely amazing. It could perhaps be a second tab in the LFO/Mod page of program edits. I think this would open up the sound design potential in a wonderful way. Imagine using a sample to modulate parameters in another sample, or having independent vibrato applied to each layer in a sample. It would be huge!
If a mod matrix isn’t in the cards, you guys could take a hint from the Elektron way and implement a few LFO’s with a diverse range of destinations. The Octatrack’s three LFO’s can modulate just about anything, and they have enough control that it kind of makes a mod matrix redundant. I could see the touch screen being put to great use if we could draw in custom LFO’s…
I know you guys have a lot of particular goals and ideas with the future of the MPC, but anything that could be done to open up modulation possibilities within the MPC would be enormously appreciated. Any chance you could comment on what the future holds in the way of modulation expansions?
2 - To take another hint from Elektron, trig conditions are a wonderful thing and they make it easy to turn a simple short sequence into something that constantly evolves and changes over time. I would love to see trig conditions implemented in the MPC’s sequencer.
3 - The looper. It is workable as it is, but it would be really nice to see it expounded upon. Having three or four looper tracks with variable speed and pre and post effect chains would be really amazing and would open up enormous possibilities for live use. I know that we can put loops into programs and sort of accomplish the same thing now, but it’s a bit clunky and not very quick or intuitive, which I find to be essential in a looper. Even just giving it the same real-time control of the now-almost-ancient DL4 would make a big difference. Having those controls for multiple loops would absolutely push the MPC into the top tier of what’s available for live looping, and probably open up the Live to a new customer base.
Re-thinking the looper and opening it up a bit could do a lot of good. A few upgrades to workflow and possibilities would be huge for all of the live loopers out there. I know I’m getting ahead of myself here, but perhaps the best way to do this would be to implement a new type of program specifically designed for looping.
Sorry to barrage you with a bit of a novel like this, but I’m really hopeful we can get some more sound design potential in the Live with modulation. It would really open up the instrument in a way that many users would love. I’m pretty sure it would make the Live irreplaceable for me. It almost is, to be honest, but a little bit of modulation would go a long way to keep up with the competition and turn this wonderful instrument you guys have made into an absolutely unstoppable monster.
I’m curious how people are handling pattern (program) changes for Elektron boxes from the MPC (or the other way around). Does it work well these days?
I do often think about getting one having used an mpc1000 extensively in the past, but it would have to integrate easily into my heavily Elektron based setup for me to go for it. I did read a while ago it was awkward, but wondered if it had been addressed in recent updates?
This is precisely what I was talking about in one of my earlier posts:
A man responsible for dozens of products, possibly hundreds of employees, and literally thousands of customers, graciously stops by a forum that he has never visited before, to make a single post out of concern for an actual bug (which may or may not be inherent to several Akai products) with the potential to destroy the hard work of serious professionals and hobbyists alike, strictly for the purposes of initiating a private email exchange between two parties, regarding said bug… Only to find himself immediately inundated with feature requests.