Lots of public discourse covering this already - so here we go again....

SSD as a memory store for sample based tone generators (engines) is very, very different from direct memory access.   SSD has so many layers between the memory and CPU.  There's a memory controller between.  There's a file hardware interface between.  There's a bus interface between (PCI or SATA).  There's the operating system's software based file system (FAT, NTFS, ext4, etc).  

What Yamaha has implemented is essentially a CPU cache for sample memory.   It's nearly the fastest level of memory storage outside of memory that is integrated into the CPU (lowest level of cache).  This memory interfaces directly to the processor tasked with tone generation.  Nothing between.   Yamaha is in complete control of the exact memory used (specs, manufacturer) as well as the hardened memory controller inside their chipset.  It's a much much tighter loop than the SSD route.

With this architecture, Yamaha could offer memory expansion through plug in boards but the current models do not have these available.  Motif an MO XF had these flash boards available but they're expensive and also eventually the memory uses goes EOL creating a problem with inventory management, requal work, etc. 

They would have to do a lot of rip and replace in order to make SSD work and probably would, in first iteration, provide a slower and more cumbersome experience than today.  They would still use lower level memory and shadow the SSD there every Performance load or maybe some other management method where other operations would go slower.

What Yamaha could do is provide a way for user samples to be compressed so you could double (at least) the available free memory.

Posted by: Jason

↑

What Yamaha could do is provide a way for user samples to be compressed so you could double (at least) the available free memory.

thank you, i see, so it is not for today that we will have solid and stable synthesizer with 250 gb of waveform memory, except with expansion board, then we are in economy management  and model business issue that is another field of discussion.

Jason covered it quite well.  I'll just add that I think Yamaha have to some extent catered to their 'many' Motif & Montage [& even MO/MODX()+] customers with every new model they release, keeping them somewhat backwards compatible, in order to make it easier for them to upgrade to the next models, including the their latest Montage M synth, at least in terms of sounds/voices.  The Montage M is a collection of all the Motif sample waveforms, plus all the Montage waveforms, and sample great new ones that they added to the M (even more since OS 2.0).  They are building on what their customers were used to in the past, especially with the AWM2 sample based engine, but also added the FM-X & AN-X.

I think in order to continue delivering all the Motif and Montage sounds, and have the synth operate with more & more polyphony, Effects handling, Arps, Sequencing, Motion Sequencing, etc., but at the same time keep the Synth solid, bug free, latency free, stable and dependable for gigging & recording musicians, they must have decided that continuing with the SWP70's (and now the new processor) was the best option to maintain stability.  And I believe the SWP70's have a particular type of memory that must be used, of which there are likely physical limitations on.  But also it's a profit based decision as well, as completely redesigning the synth for an NVMe SSD based system would be a huge costly venture, and would it be as stable & latency free as the current setup..!?  Plus I believe Yamaha may design & utilize some of the chips that go into their Synths, which I don't think are compatible with NVMe SSD's, so they would need to completely redesign the tone generators and other chips, as well as likely the entire board.

It sounds like you may have SampleRobot, since you have a Montage classic..!?  If so, maybe consider digitally sampling the Montage articulated choir or string, etc., maybe more focused on the ranges that you need, maybe every second or third note, maybe find the best seamless loop points, and add create some new libraries with the sounds you need, with less GB required..!?  Maybe create multiple libraries and load the ones that you need when you want to utilize them.  I wish I had the money to trade up to a Montage M and have to deal with the problem of having much lower User memory compared to SSD 😋 

This would allow you to utilize the extra 128 note polyphony on AWM2 from user memory as well, thereby doubling your polyphony.

And remember the M has double the User/Library memory that the Montage classic has, as well as twice the number of Library slots to have loaded at any given time!  😉 

Posted by: Jason

↑

What Yamaha could do is provide a way for user samples to be compressed so you could double (at least) the available free memory.

I don't think they will provide this functionality on the M.  I added an IdeaScale idea for this, and they rejected it quite quickly for the Montage classic.

I hope I'm wrong, as maybe they left room in the design of the M for converting waveforms loaded in User memory via their proprietary compression?  Perhaps it might be possible at some point in a future OS update with single waveforms that are loaded, but maybe not as likely for converting Libraries..!?  And I don't think they are going to give out their converter to 3rd parties like John Melas, SampleRobot or Sound Pack/Library developers...

Posted by: Darryl

↑

  I wish I had the money to trade up to a Montage M and have to deal with the problem of having much lower User memory compared to SSD 😋 

I agree 😪 

Posted by: Darryl

↑

Jason covered it quite well.  I'll just add that I think Yamaha have to some extent catered to their 'many' Motif & Montage [& even MO/MODX()+] customers with every new model they release, keeping them somewhat backwards compatible, in order to make it easier for them to upgrade to the next models, including the their latest Montage M synth, at least in terms of sounds/voices.

I just had a similar discussion on the Kronos forums about the path the big 3 have taken in their flagship upgrades. For Korg, the Kronos and Nautilus are essentially just an expansion of the Oasys. You can see in the OS / UI that they've just been evolving the same thing with each new line, and I suspect Yamaha has done something similar with Motif / Montage / M.

Like you said, reinventing the wheel is risky and costly, which is why hardly anyone does it. You take a platform that's been around long enough to be debugged and stable, then figure out how to expand and enhance it. With this approach, you're limited by the architecture you're vamping on. On the other hand, you have far fewer "1.0" bugs, not to mention a heckuva lot lower R&D cost to get it out the door (which would be reflected in price).

Roland kept the same hardware and just did an OS upgrade to the EX (their "Fantom M", so to speak). And I have no idea what Korg was thinking with the Nautilus, which is essentially the sibling of the ModX, i.e. "flagship lite." Yamaha is the only one who has thrown significantly improved hardware into their latest flagship upgrade, so kudos to them for that move.

All hardware and software have limitations, and there's a never ending list of what customers would like to see added, but the M8x I have is a fabulous machine. If I hit the wall with memory / disk limitations, I'll just archive things and clear some room (starting with a ton of the stock performances that I'll never use). Power users may hit this limitation sooner than me, but for a guy who just wants to play I'm unlikely to hit that wall anytime soon.

I don't think they will provide this functionality on the M.

It is my understanding that user waveforms ARE compressed just not with Yamaha's proprietary algorithm they use for the preset waveforms.

So it could be possible in an OS update to use a more effective compression scheme without using the proprietary one.

The basic choice is between a 'lossless' algorithm versus a 'lossy' algorithm. The former typically doesn't provide as great a compression ratio but ensures that, as the name implies, there is no loss of info when you decompress the data.

It is also possible to take into account that, for audio, the speed of decompression is much more important than the speed of compression.

That makes it possible to analyze individual source audio samples to determine the most efficient algorithm to use for each sample even if you want to consider 5 different algorithms before choosing one. You don't really have to compress the samples in real-time. That analysis can find, and take advantage of, audio sections that are primarily low (or high) frequency and use a more efficient encoding for them.

On the other hand fast, real-time, decompression is critical. Not a problem since the compressed file will already contain a flag indicating what algorithm was used to compress it. So the only 'waste' is the memory needed to store multiple decompression algorithms.

Interesting video, for me at least, inside the beast

Montage M: All the Inner Secrets of Yamaha's Flagship Synth - YouTube

Posted by: Toby

↑

It is my understanding that user waveforms ARE compressed just not with Yamaha's proprietary algorithm they use for the preset waveforms.So it could be possible in an OS update to use a more effective compression scheme without using the proprietary one.

It is also possible to take into account that, for audio, the speed of decompression is much more important than the speed of compression.

On the other hand fast, real-time, decompression is critical.

That would be interesting if it is the case, because I watch closely the amount of memory that I have left after every .wav file or library that I import into User/Library memory, and it appears to reduce the available memory by the same amount/size of the .wav file or library that I import, sometimes more than expected.

So 'if' they are using some kind of compression, it is not great compression IMHO.  Therefore, unless I hear if from Yamaha or someone that fully understands the Montage OS code & compression (or lack there of), I am going to assume they do not compress .wav files or library waveforms.

I do agree that the speed of decompression is critical for audio, which is another reason that I have doubts they are using another kind of compression on any .wav files or libraries that I import, because I would think that Yamaha's proprietary compression was developed specifically to maximize decompression, so for them to use a different type of compression for custom non-Preset waveforms wouldn't make a lot of sense to me, since it could slow down the decompression...and since as far as I can tell the custom waveforms are barely (if any) being compressed, it doesn't seem worth it.  So that makes me lean even further away from the belief/guess that they are compressing User memory...

Perhaps Yamaha or someone with knowledge of the Force on Montage's can pipe in & clarify?  😆 

I watch closely the amount of memory that I have left after every .wav file or library that I import into User/Library memory, and it appears to reduce the available memory by the same amount/size of the .wav file or library that I import

Based on that I:

1. did a factory reset - 0 user space indicated

2. loaded the Chick Corea V library - 400 mb user space indicated

3. did a library import of ALL library performances - 800 mb user space indicated

4. deleted the library - 400 mb user space indicated.

This is the source of the library

https://shop.usa.yamaha.com/en/p/downloadables/sound-expansion-library/synth-voice-libraries/chicks-mark-v-montage

5 Waveforms, 874 Keybanks. Linear data = 1.1GB, Compressed = 423.5MB

That would suggest to me that the library waveforms were compressed with Yamaha's proprietary algorithm.

So the likely takeaway is that there is no ONBOARD compression at all including for the proprietary algorithm.

Here is an interesting article on how that Chick library was created

https://hub.yamaha.com/keyboards/k-artists/how-to-incorporate-a-piece-of-musical-history-into-your-montage/

Not sure how starting with Yamaha produced content that is known to be compressed demonstrates or information anything other than the possibility for compression which was already a given.   It's user raw WAV or AIFF files imported that would need onboard compression so user content can benefit.  Not on the fly, but as you load the files and maybe an option to bypass if you don't want to invest the extra time.  I say this because it would likely need to be a CPU driven operation without DMA or straight copying "bulk" transfers which would tend to take significantly longer.  Worth the wait if you wanted to save the space but not worth the wait for more casual usage.  

Of course an external tool would be "better" similar to the tool given to 3rd party content providers but this may be seen as a "security risk" (as in the security of their proprietary compression algorithms).   

And also, for security, the saved user/backup files would save decompressed which itself would probably take a long time for user audio data.

I'm not here to dictate how exactly this would be implemented but do understand (speculatively) the rationale(s) for not offering this high level feature.  The feature to allow customers to end up with compressed user audio (loaded from their own WAV and AIFF files) if they want it.

Not sure how starting with Yamaha produced content that is known to be compressed demonstrates or information anything other than the possibility for compression which was already a given

There have been previous, older, comments that since the user data is in a separate storage that there was no onboard way to decompress anything in that storage. And that separate storage is accessed by a separate SWP2 chip meaning it uses a different access path than that used for preset storage.

So that 'possibility for compression' isn't necessarily a 'given' as it applies to user storage. The info I provided shows that it should be possible to use an OS update, rather than a hardware update, to add on-board compression/decompression for the user area independent of the proprietary method.

That could be a nice future benefit without requiring additional hardware.

When I think about how long it takes to load a .wav file or a library, I wonder if (as Jason already mentioned) if it would take a really long time to also apply Yamaha's proprietary compression, so much that it would take an unreasonable amount of time & not worth it..!?  Perhaps though, if the compression part was done via the new processor it could be relatively quick.  So maybe it is possible via an OS update for Yamaha to provide the ability to compress custom User samples in a reasonable time; However seeing as how quickly they rejected my idea to allow something like this on the Montage, I still have my doubts that they would allow this functionality on the M.  Hopefully my guess is wrong...