DAMN the RAM!

Well, we have run into a little snag. We started to put together a new video showing the mapping of OAX user sounds to four Kontakt instruments banks. You can go back and review the last two videos to see where we (thought) we were headed.

We ended up with 12 samples loaded in each Instrument Bank and 4 Instrument Banks set up in Kontakt. Those four Instrument Banks mapped to Upper1, Upper2, Lower1 and Lower2 on the OAX side. We need to do a little more verification but it looks like that isn’t going to work with the default 8GB RAM config on our Sonic. You can see in the screenshot below with 3 of the 4 Instrument banks loaded we are sitting @ 78% of memory in use. At this point none of the VST sounds would play and the whole “VSTHOST” interface on OAX locks up. We haven’t had time yet but I do plan to re-create this config outside of the Sonic on a stand-alone PC as I’m curious to see what will happen.

There were some comments from others that were running into similar issues when attempting to load up some of the Albion Sting samples. Our plan has always been to max out memory on our Sonic to 32GB – Perhaps we will be doing that sooner than we expected!

For now, just wanted to update everyone on where we are. I need to rethink the video and the best way to show you how we will use the samples we own, pending future memory upgrades. On a related note, I think we will build a second set of Instrument Banks using the Kontakt demo sounds, which are much smaller samples, to show that it does work on multiple OAX keyboards & selectors but, sample size vs. available RAM in your Sonic will change what and how you implement things. Of course you can always choose to use an external PC to host VST’s and leave OAX “as-is”…. but what fun is that? 🙂

10 thoughts on “DAMN the RAM!

  • 09/19/2017 at 15:36
    Permalink

    Hey Mark,

    A little early to say just yet. I did think about the page file. A quick look and it is configured by Wersi to allow Windows to “decide”. I don’t have the window open anymore but if I remember right the page file was something like 2 GB in size. At this point I’m going with your comment – We have “over-commited” memory. The page file is in the default location on the C: drive.

    One thing I know for sure is that was I was not able to modify the page file settings using the default logon. How did I get there? Simply by escaping to the Windows desktop and navigating to the page file settings. My first thought is that the account that we (OAX) are running with may not have full admin rights although I’ve been able to make quite few other changes without any issues – Hmm.

    More work (Fun ?) to do on this front.

    Reply
    • 09/19/2017 at 16:55
      Permalink

      Hi Curt,

      See this link https://support.microsoft.com/en-gb/help/2860880/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of

      If the pagefile is system managed and thus has the ability to expand up to 3x system RAM, then this is when it will extend in chunks, and potentially end up fragmented across the disk. As you can’t defrag the pagefile.sys, might be best to try and delete it and re-create at a more reasonable size, such as 24GB, so that it gets the whole allocation in one contiguous lump. Obviously if you are calling upon the 8GB of real memory and stressing the 24GB of pagefile (32GB of virtual storage in total) you have requirements that only a significant upgrade of Physical RAM, as you are planning, will fix.

      Thanks
      Mark

      Reply
  • 09/19/2017 at 14:16
    Permalink

    Hi Curt
    You are now running into exactly the problems I was experiencing when trying to load multiple banks of large samples, so put the project on hold at present.

    In the meantime I had the opportunity to pickup a Bohm Silverbird Expander at a very affordable cost which I have integrated into the Sonic and at present am getting to grips with this.

    Chris

    Reply
    • 09/19/2017 at 15:26
      Permalink

      Hey Chris,

      I thought you had more than 8GB on your Sonic or I am confusing you with someone else? I have to Google “Bohm Silverbird Expander” to learn more but sounds interesting. Please keep all of us posted on your adventures!

      Reply
      • 09/20/2017 at 09:24
        Permalink

        You confused with me , Curt. I purchased my 600 with maximum RAM.
        Samuel

        Reply
        • 09/20/2017 at 09:46
          Permalink

          Thanks for the reminder Samuel! I just sent a note off to Wersi to clarify this statement which is located in the last section of the 1.45 Programming manual: The translation is a little rough but before I do anything with RAM increases I want to verify:

          The hardware is controlled by the system code and is calculated from all the components used in your instrument. The system code is a distinctive Fingerprint your instrument. If components (motherboards, RAM, processor ….) In your exchange instrument, the system code changes result go activations lost and the instrument can no longer be used.

          Check with them this first with WERSI in before you plan to install “foreign” soft-plan hardware extensions, you buy it only at WERSI.

          Reply
          • 09/20/2017 at 13:45
            Permalink

            Hi Curt,

            I think they may mean the Win10 activation code, as that is linked to certain bits of hardware, but didn’t think it related to RAM. If you change motherboard for example, you have to reactivate Windows as it generates a new hash code.

            I have a meeting with Microsoft next week, so could ask if you want anything clarified post Wersi’s response.

            Cheers
            Mark

          • 09/20/2017 at 14:12
            Permalink

            I did hear back from Wersi support. Here’s what they said. Since I don’t have any expansion packs I should be OK to add RAM at the PC level. I’ll be “shopping” in the coming days. Who knew making / playing music cost so much money!

            Ok – There is the part of me messy around WAY too much — 🙂

            HI,

            That is not correct.

            ” The OAX system offers you the possibility to activate expansion packages
            via so-called activation keys. Your instrument is equipped with a security
            chip. This chip gives your instrument a unique and distinctive instrument ID
            in the form of a combination of numbers and letters.”

          • 09/20/2017 at 14:19
            Permalink

            Hi Curt

            Since Windows XP activation has been required, which checks the components in your system, and if there are any major changes (CPU, Motherboard etc.) it has to be reactivated as it believes you are trying to load it on more than one computer.
            You can add components without problems and also change the installed Ram and SSD/HDD, number of PCI cards etc. a number of times before reactivation is required.

            Wersi probably either use the code in the OS (Which means it changes if you alter too much) to tie in OAX, or they tie it into the Wersi hardware (Like they did in OAS) that is on-board.

            DO NOT change any of the Windows settings unless instructed by Wersi, as you could end up with problems. (OAS owners had a habit of doing this and totally cocking the system up)

            Note: UNDER NO CIRCUMSTANCES defrag an SSD as you will seriously reduce its life span. (It will also have zero effect on the performance of the system)

            Have fun

            Bill

  • 09/19/2017 at 14:03
    Permalink

    Hi Curt, glad to see you are back in action and escaped the brunt of Irma.

    Irrespective of memory utilisation, which at this level of reporting is pretty crude, are you seeing much paging activity. Also is pagefile.sys big enough, contiguous and on a separate drive to the apps. For the non-techies reading this, when you run out of RAM which operates in nano-seconds, the system will page out or move the least frequently used blocks of RAM contents to a file on disk, which operates in milli-seconds, so an order of magnitude of difference. This is generally not a problem providing it is at a low level, however when you drastically over commit RAM, such that least frequently used and frequently used are very similar, then Windows has to move lots of blocks of memory to disk in order to free space to bring lots of blocks from disk back into RAM in order to run, and this is very slow by comparison. When this becomes constant (which we call thrashing) effectively grinds a system to a halt. In most cases system become unresponsive, but can also crash when timed events are involved.

    I would expect you to see very different behaviour on a standalone PC, as you will only have Windows and Kontakt Player competing for resources.

    On the Sonic, I don’t know how Windows will prioritise paging activity between OAX and Kontakt, as I am assuming that they will both run as separate processes, with Kontakt spawned by OAX – I also assume they will both run at equal priority.

    Might be worth playing around with prioritisation of OAX and Kontakt in task manager to see if you can influence what happens under resource constraint.

    Also, is Kontakt a 32 bit or 64 bit app, as that will impact the amount of memory that can be addressed.

    But of an unstructured brain dump, and I have tried to be as non techie as I can to keep everyone interested, so please feel free to amend.

    Cheers
    Mark

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *