In Sample Edit, how do you SAVE the sample?

Directly after recording a sample, in the lower left corner of the KEEP OR DISCARD SAMPLE screen there's an option to SAVE the newly recorded sample to a wav file. But if you go to Sample Edit instead, how do you then save the sample to a wav file? You can't go back to the KEEP OR DISCARD SAMPLE question.

Main > pencil icon program row > save current sample

Usually works as long as you don't hit a pad during the process, if you do I think it will offer to save the sample in layer 1 of the pad you hit

I put in a feature request for a save button in sample edit years ago. It's this kind of stuff they should be fixing imo, getting rid of these silly things that slow you down

Thanks! Yeah that's weird. I actually went through the same steps when trying to figure out how to save the Program. But ok. You save a Sample from the Main screen's menu that lists program-editing functions. Not from the editor, not any "file" menu or anything like it. It doesn't make any sense. Hey, I used to use Amiga ProTracker etc., the MPC is in no way exceptional. But at least ProTracker had "Disk Op" that had disk-related stuff.

I bet alot of us have thought the same thing. The save function is already coded and in use. the bit of menu code to string that save function together with the sample editor ui wouldnt be much work for the developers however i kind of feel like with the limited system the software is running on, saving ram is a major concern. The mpc software in 2.10 came down from around 47mb to 36mb yet has more features so they must be doing some decent optimisation. The save feature linked to the sample editor ui would be a few kb if that though... no real reason as to why *not* to do that.

One of the main problems with any software change, whether it's optimisation (=do the same thing as before, but somehow better, e.g. with lower resource consumption, or with code that's more manageable/understandable/robust/etc), new feature (=do something new or more than before), or bug fix (=make the software do what it promises to do), is that the change may potentially break something. There are automated testing methods and tools that help in this, but if the change is visible in the user interface, there's the additional burden of changing documentation etc. And even if all of this is OK, the change still needs at least one developer hour, which must be approved of by Management (or done without permission). From an organizational perspective, there are many ways to undermine this, and end up making a bad product. In a sense it's a miracle that there are any software products at all.