2.3 better feel like 3.0!

Thats why Tutor is THEE MPC guy/guru.

Anyone knows a cash grab method is a limited run and bound to crash head on into the pavement. If Akai wants long term money, then they need to wise up and listen to real users like Tutor and us.

MPC-Tutor wrote:

Bezo wrote:So it's a balance of quality vs efficiency? You get one, the other, or a bit of both. But you can't have it all..

...Things get tricky with acoustic instruments, you do have to make compromises, I try to keep acoustic programs under 120MB but you have to reduce keygroups, use mono, maybe truncate some natural decays, use looping, reduce some layers etc. But if you are careful it should still sound excellent, just not 'Kontakt instrument excellent'.

So yes, more memory would be great, as would better keygroup features. But lazy sound developers don't help matters. It's only going to get worse though, lots of sites now accepting third party sampepacks with zero quality control, and more tools coming to make it easier to pump out 'by the numbers expansions'.

I figured. Yeah, it's the acoustic instruments I'm talking about.

CharlesRandolph wrote:

Bezo wrote:So it's a balance of quality vs efficiency? You get one, the other, or a bit of both. But you can't have it all.

Yeah, this thing needs more RAM.

You can have both, but you're going to have to use the larger sound sets with laptop/desktop. The MPC X and Live were not designed, to handle multiple large sample sets. That can change if Akai Pro adds streaming from disk...

I have plugins for that. I need multi-sampled instruments specifically for stand alone mode.



I dig the MPC workflow way too much. The Live was NOT made for folks that make music the way I do.

MPC-Tutor wrote:

soundsafoolmusic wrote:Some of the purchased key groups I load have 4 samples per key accoss 88 notes. (Especially pianos).

I see you have the Concert Grand from me, that one was a big one if you used the fully chromatic version, the 'compact' xpm program provided uses significantly less memory. I've since created a new piano pack for the Live/X, The Piano Suite, these acoustic pianos are around 100MB each (still 4 velocity layers).

All my latest keygroup expansions are highly optimised, even the acoustic ones, so you should be able to load many keygroups into memory.

https://www.mpc-samples.com/section.php ... struments/

I know some other developers are putting out some ridiculously memory intensive packs, with synth bass programs running at over 200MB each which is completely unnecessary and overkill for a mono synth instrument. If you multisample correctly, employ sustain looping, use built in filters and lfo, synth bass programs shouldn't be more than a few MB each and still sound amazing. That however takes a lot of effort for the developer so most of them don't bother.

I downloaded the demo instrument for a certain unnamed company's latest 'vintage instrument' expansion release, every single sample in the demo instrument is the exact same length, 12 seconds, regardless of whether or not there is actual audio data taking up that whole 12 seconds. The higher notes have less than 1 second of actual audio, 11 seconds of dead space.

Obviously completely automated chopping, I suspect they even used my VST2MPC workflow template to do the multisampling in the first instance as that employs equal region chopping. However if you are going to use that template in a commercial kit, you need to do the extra work and at least top and tail the samples where required.

The problem is, I wonder how many people these days actually give a **** about this kind of stuff. Personally I think if you are going to specifically claim your expansions are 'designed for standalone' you should be doing everything possible to reduce their memory footprint for a memory limited standalone machine. Otherwise, WTF does 'designed for standalone' actually mean?

Thanks Andy - it was actually someone else variations on piano via his 'repository pack' that has given me the issues. Yours have been fine and i can load quite few key groups if using yours.

Ill-Green wrote:Thats why Tutor is THEE MPC guy/guru.

Anyone knows a cash grab method is a limited run and bound to crash head on into the pavement. If Akai wants long term money, then they need to wise up and listen to real users like Tutor and us.

Yes, Long term comes from consistent quality machines. However, they also need quick turn around release that can generate money. Be it cables, paid updates, new apps, partnership devices, and so on. Small cash grabs fund bigger projects.

i think akai have purposely crippled the mpc , the cpu and memory isnt doing anything near its capible of , but i think they have done it for a reason, and the cpu board is quite unstable hense so many problems with the first few batches of software, the software mpc OS is unstable based on Linux with flakey drivers for the componants inside . either the software on the mac as standalone gets a complete overhaul or we wont see any big changes, join the mpc hacking group on Facebook for some interesting information about the hardware!

forsh wrote:i think akai have purposely crippled the mpc , the cpu and memory isnt doing anything near its capible of , but i think they have done it for a reason, and the cpu board is quite unstable hense so many problems with the first few batches of software, the software mpc OS is unstable based on Linux with flakey drivers for the componants inside . either the software on the mac as standalone gets a complete overhaul or we wont see any big changes, join the mpc hacking group on Facebook for some interesting information about the hardware!

Why not start the MPC hacking group thread here. That way the information is public for those who don't use facebook.

i dont really come here so often otherwise i would, and i would like it a bit more sturctured , sections, headings etc, thats to much to ask from a forum i rarely come to

forsh wrote:i dont really come here so often otherwise i would, and i would like it a bit more sturctured , sections, headings etc, thats to much to ask from a forum i rarely come to

I see, well if you have anything cool, try posting it here as well. Many 4000 user are looking for a person who can write a driver for windows 10. Any luck in that department?

What has the hacking group accomplished thus far? Last year we had a guy that was using a mouse with his MPC. Is the group looking for such hacks?

I'd love to see what's in the hacking group, but I'm not on Facebook and it doesn't show up in normal search engines. Can you post a direct link?

CharlesRandolph wrote:

Bezo wrote:So it's a balance of quality vs efficiency? You get one, the other, or a bit of both. But you can't have it all.

Yeah, this thing needs more RAM.

You can have both, but you're going to have to use the larger sound sets with laptop/desktop. The MPC X and Live were not designed, to handle multiple large sample sets. That can change if Akai Pro adds streaming from disk.

Nevertheless, there are companies who are not optimizing their sounds. All they have to do is truncating the sounds and stop re-recording or upconverting 16 bit sound to 24 bit. All it does is add file size, but does nothing for the quality.

I agree with this opinion 100%, except I am unclear about the part where they convert to 24-bit. According to other posts, I've read that samples are imported as 32-bit (floating point).

This means that a 16-bit WAV file essentially doubles in size when loaded into memory, that is pretty screwed up, considering.

A simple example of the issue, I have a WAV from a CD (single track) and it's 594 MB (623,678,526 bytes for the tech savvy). This is a 16-bit 44,100 Hz Stereo WAV file extracted directly from the CD. So, a bit of calculations in accordance with what I've read, this will result in 32-bit 44,100 Hz Stereo in memory, which means a 1,188 MB chunk of RAM.

In other words, in a fresh new project it cannot be loaded at all "Not enough memory to load sample". This is a huge waste of resources. If this thing had like 8/16 GB, it wouldn't be that big of a deal, but with 2 GB, well, use your greys and have your own opinion.

Now, *IF* the MPC can and Akai wanted, to pull off disk streaming, *OR* optionally allow samples to load "as is" into memory and expand to 32-bit float while playing, then the RAM would in essence, I would venture to guess in most cases (obviously not all), be double in size. My file above, as an example, would be much more likely to load (not necessarily, of course).

Some audio could use even less bits and save more room. Lots of sample content don't need this kind of fidelity. Meaning, people could also then (but not as it is) affect our own availability of RAM in the MPC X/Live.

Another help with larger files would be to expand the audition and the load attributes. Enable us to move about in the file (on disk) and listen to any part, not just in the beginning of the file. When the "where" is found we would be able to load a selected segment size, which can be more finely adjusted once loaded into memory.

MPC-Tutor wrote:Personally I think if you are going to specifically claim your expansions are 'designed for standalone' you should be doing everything possible to reduce their memory footprint for a memory limited standalone machine. Otherwise, WTF does 'designed for standalone' actually mean?

Agreed, and as my earlier post in this thread is related, this also applies to Akai using the term 'standalone' as well. The waste of memory in terms of the MPC X/Live really is "worst case scenario". Well, OK, I suppose they COULD have chosen 64-bit, so "one bit from worst case".

I cannot imagine that this is NOT because of get-it-out-the-door decisions.

Same thing with absolute minimal MIDI implementation in software. I mean hardware wise, there is nothing like it, but software wise it's 30 years behind the curve. That is difficult to rationalize as a customer.

Elektrobolt wrote:This means that a 16-bit WAV file essentially doubles in size when loaded into memory, that is pretty screwed up, considering.

Converting audio to 32 bit float is pretty standard in modern software applications, remember this is just a Linux computer running the MPC Software so it will use the same processing as the Mac/PC version. It isn't screwed up at all, I believe it's pretty much required in terms of efficiently and accurately processing the audio data.

MPC-Tutor wrote:

Elektrobolt wrote:This means that a 16-bit WAV file essentially doubles in size when loaded into memory, that is pretty screwed up, considering.

Converting audio to 32 bit float is pretty standard in modern software applications, remember this is just a Linux computer running the MPC Software so it will use the same processing as the Mac/PC version. It isn't screwed up at all, I believe it's pretty much required in terms of efficiently and accurately processing the audio data.

Is the MPC operating in 32-bit floating point?
I may be wrong but I *think* I recall tracks distorting when hitting the red – which is not good practice, but in 32-bit floating point systems, *tracks* hitting red should not distort the sound as long as master stays on the green.

http://fanumusic.com/is-it-ok-to-run-tr ... -in-a-daw/

MPC-Tutor wrote:

Elektrobolt wrote:This means that a 16-bit WAV file essentially doubles in size when loaded into memory, that is pretty screwed up, considering.

Converting audio to 32 bit float is pretty standard in modern software applications, remember this is just a Linux computer running the MPC Software so it will use the same processing as the Mac/PC version. It isn't screwed up at all, I believe it's pretty much required in terms of efficiently and accurately processing the audio data.

Obviously, I was not being clear. I do apologize for that.

There is nothing wrong with the format per se, of course.

It's having a limited 2 GB of RAM and expand all lower formats (e.g. 16-bit) to 32-bit in memory. That is a crazy waste of resources. This "expansion" of bits, could be done while playing lower formats from memory, or at least provide the option for people to do that, if they need more room in the box, and can live with a bit more CPU allocated for the real-time conversion.

Since you brought up computers, many applications and plug-ins do this conversion from whatever file formats you have your audio files stored in, e.g. Steinberg HALion (and they also stream directly from disk).