• Register
  • Help
Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Topic: GPO Studio Requires Samples on C: Drive?

Share/Bookmark
  1. #1

    GPO Studio Requires Samples on C: Drive?

    I'm not the first person to notice this, as it's been discussed in the general forum in the "GPO Benchmark" thread, but I don't see it having been brought up here in the support forum.

    Apparently, GPO Studio has been built so that it can *only* function if the samples have been installed on the C: drive. Is this really the case? It is standard practice for many, many DAW users to keep their samples on a seperate partition or drive, to reduce fragmentation effects. And those of us who use laptop DAWs have the additional motivation of putting samples on a FireWire drive that's faster than the built-in laptop drive. Was GPO really targeted 100% at amateurs who put everything on C:?

  2. #2

    Re: GPO Studio Requires Samples on C: Drive?

    This is probably related to the cross-platform incompatibility issue with GPO Studio files...PC .gpo files cannot be opened on a Mac; it results in the missing-sample dialog and won't even recognize the GPO .nks files as valid. It has something to do with the way NI encrypts the sample archives - David at Plogue explained to me that GPO Studio really has no way to look inside the "black box" of Kontakt Player's file management. So this is something NI needs to fix.

  3. #3

    Re: GPO Studio Requires Samples on C: Drive?

    Kevin,

    You bring up a subject that goes beyond the specific issue with GPO Studio: The relevance of separate/faster hard drives when using GPO. Keep in mind that GPO is designed to operate entirely in RAM. Unlike libraries that rely on streaming technology, drive location and speed are irrelevant to GPO performance (with the possible exception of instrument load time). Once samples are loaded into RAM the source location of the samples is no longer involved. Under these conditions GPO will perform precisely the same way if the library resides on a 5400 spin drive or on a 10,000 spin drive. Even if a “sample locate” problem didn’t exist drive location and speed would be unimportant to performance. The drive is out of the equation once the samples are loaded into RAM. Drive fragmentation is also not a concern for the same reasons.

    If and when DFD is instituted the usual streaming rules will apply concerning drive performance/bus allocation. The option of placing the samples on separate drives so that users can organize things for best streaming performance will become desirable. Now, here’s the important part: If and when DFD is added to the player it will exist only as a convenience to users. The library will continue to provide the best performance when the user chooses to load everything into RAM - better polyphony, lower CPU usage, and better internal performance. A good example of the last part of this statement is crossfade looping. Any samples (fortunately there are few in GPO) that use zone-level crossfade loops lose those crossfades when streaming. This is unavoidable, because the program can’t “know” the information in advance without actually loading the entire sample, which of course negates the purpose of streaming. For this and other reasons I will continue to strongly recommend using the library in RAM whenever possible.

    Was GPO aimed entirely at non-professionals? Of course not. It was designed to be used by professionals and amateurs alike. In this day of inexpensive hard drives with huge capacities we expected almost all users to have 2Gb to spare on their C drives for GPO since no performance advantage was to be gained by placing it elsewhere. For the most part this has proved to be true with users. That expectation will change if and when we add DFD capability. I’ll leave all comments about GPO Studio performance to Jeff.

    Tom

  4. #4

    Re: GPO Studio Requires Samples on C: Drive?

    Quote Originally Posted by Tom Hopkins
    Kevin,

    You bring up a subject that goes beyond the specific issue with GPO Studio: The relevance of separate/faster hard drives when using GPO. Keep in mind that GPO is designed to operate entirely in RAM. Unlike libraries that rely on streaming technology, drive location and speed are irrelevant to GPO performance (with the possible exception of instrument load time). Once samples are loaded into RAM the source location of the samples is no longer involved. Under these conditions GPO will perform precisely the same way if the library resides on a 5400 spin drive or on a 10,000 spin drive. Even if a “sample locate” problem didn’t exist drive location and speed would be unimportant to performance. The drive is out of the equation once the samples are loaded into RAM. Drive fragmentation is also not a concern for the same reasons.
    I realize that to some degree it's your job, first and foremost, to defend GPO, but please think this through just a little further. Those of us who have more than just GPO on our DAWs often have other soft samplers installed. I have three of them, two of which are DFD capable. I organize my disks, not purely as a function of GPO, but of the total set of tools and workflow, and I made the decision - a relatively common one - to keep my samples off the C: drive. The GPO installation procedure even recognizes this - it allowed me to specify a different drive than the program installation drive for the samples. One could argue that it's an incoherence in the GPO package design that the installer gives users the option of installing the samples where they cannot be used by GPO Studio et. al.

    Secondly, you're simply wrong when you say that disk performance doesn't matter if you're not streaming DFD. Startup/load time for a project *does* matter, and in a project using large sample sets, that's dominated by the performance of the disk containing the samples. The difference between a fast drive with a contiguous layout and a fragmented, slow, laptop C: drive can be *huge*.
    If and when DFD is instituted the usual streaming rules will apply concerning drive performance/bus allocation.
    If and when???? That sounds like quite a climb-down from the nods-and-winks that I've been seeing in these forums and elsewhere that DFD would be part of a forthcoming update/patch. I find this quite worrisome. My DAW has 1GB of RAM, and as it's a laptop with 512MB built-in and a matching 512MB added, it's not likely that I'm going to add any more, but the full GPO "benchmark" won't quite run cleanly on the system. To be honest, when I bought GPO, I had simply *assumed* that it had DFD, since it uses a Kontakt player and even my old version 1.2 of Kontakt does DFD.

    On further reflection, if it's true that the samples themselves (as opposed to the meta-data) are encrypted, I guess you (and by extension we, the customers) could be screwed - NI may have chosen an encryption algorithm too heaviweight to support on-the-fly decryption doing DFD. That would have been aggressively stupid, but alas, it wouldn't be the first time such a thing has happened.
    The option of placing the samples on separate drives so that users can organize things for best streaming performance will become desirable. Now, here’s the important part: If and when DFD is added to the player it will exist only as a convenience to users. The library will continue to provide the best performance when the user chooses to load everything into RAM - better polyphony, lower CPU usage, and better internal performance.
    That's true of any DFD sampler setup. I think that most of us who use DFD do so selectively, when it's a question of either streaming or not being able to use the sample set *at all*.
    A good example of the last part of this statement is crossfade looping. Any samples (fortunately there are few in GPO) that use zone-level crossfade loops lose those crossfades when streaming. This is unavoidable, because the program can’t “know” the information in advance without actually loading the entire sample, which of course negates the purpose of streaming.
    If this is true, it's a bug in NI's sample format. It's certainly not an unavoidable consequence of streaming.

    Sorry if I was a bit sharp in this rebuttal, Tom. I really do appreciate your taking the time to respond in detail. But denying that there's a problem here just doesn't cut it with me.

  5. #5

    Re: GPO Studio Requires Samples on C: Drive?

    Kevin,

    “I realize that to some degree it's your job, first and foremost, to defend GPO, but please think this through just a little further. Those of us who have more than just GPO on our DAWs often have other soft samplers installed. I have three of them, two of which are DFD capable. I organize my disks, not purely as a function of GPO, but of the total set of tools and workflow, and I made the decision - a relatively common one - to keep my samples off the C: drive.”

    (TH) I was not offering a defense but, rather, a explanation of what elements are most important to get the best performance out of GPO and what elements aren’t. From your description it is still unclear to me why placing GPO samples on your C drive would in any way affect your set of tools, interrupt your workflow, or damage the peaceful coexistence of GPO with other soft samplers. Certainly if streaming was involved a tug-of-war for resources could become an issue, but in RAM? I must be missing something here.

    “The GPO installation procedure even recognizes this - it allowed me to specify a different drive than the program installation drive for the samples. One could argue that it's an incoherence in the GPO package design that the installer gives users the option of installing the samples where they cannot be used by GPO Studio et. al.”

    (TH) If indeed the present version of GPO Studio (as appears to be the case) cannot access samples placed on an alternate drive then it is very much an “incoherence,” as you put it. No argument there. I would hope that this problem would be addressed in the future by the designers of the software. For now, it is just another reason to place GPO on the C drive if one wishes to use the programs as designed (assuming that solves the problem). Again, I’m not defending this, I’m just stating the practical fact of the matter as it apparently exists now.

    ”Secondly, you're simply wrong when you say that disk performance doesn't matter if you're not streaming DFD. Startup/load time for a project *does* matter, and in a project using large sample sets, that's dominated by the performance of the disk containing the samples. The difference between a fast drive with a contiguous layout and a fragmented, slow, laptop C: drive can be *huge*.”

    (TH) Pardon me but I am absolutely right when I say that performance of GPO is independent of drive speed once the samples are loaded. That’s all I said. Now, as far as the impact of the load speed for large projects, your experience and mine are quite different. On my three systems the difference in loading performance between drives has been negligible. Then again, I use identical speed drives throughout my system and I don’t let my drives get significantly fragmented. This could account for our differing experience. If you’ll re-read my post you’ll see that my comments referred to performance in RAM after loading (I even excepted loading from the discussion since it was a possible variable).


    Quote:
    If and when DFD is instituted the usual streaming rules will apply concerning drive performance/bus allocation.
    “If and when???? That sounds like quite a climb-down from the nods-and-winks that I've been seeing in these forums and elsewhere that DFD would be part of a forthcoming update/patch. I find this quite worrisome . . .”

    (TH) The “if and when” is there simply because any other comment would be premature concerning an unreleased product. The statement is nothing more than non-committal. Don’t read anything else into it.


    Quote:
    A good example of the last part of this statement is crossfade looping. Any samples (fortunately there are few in GPO) that use zone-level crossfade loops lose those crossfades when streaming. This is unavoidable, because the program can’t “know” the information in advance without actually loading the entire sample, which of course negates the purpose of streaming.
    “If this is true, it's a bug in NI's sample format. It's certainly not an unavoidable consequence of streaming.”

    (TH) Fine, whatever you say. It is the way I’ve described it in its present form and that is what we have to deal with as a practical matter. No one would be more pleased than me if my statement turned out to be incorrect.

    ”But denying that there's a problem here just doesn't cut it with me.”

    (TH) At no point have I denied that there is a problem for users of GPO Studio who place the samples on a drive other than C. I didn’t address anything to do with GPO Studio in my post. The entire thrust of my post was to emphasize two things only:

    1. GPO is fundamentally designed to perform best in RAM and will continue to do so even if and when (oops, there I go again!) we institute streaming.
    2. Drive performance has no impact on performance once the samples are loaded.

    I chose to make the second point because users reading your original post could have easily gotten the mistaken impression that drive performance was relevant during sample playback. If placing GPO on your C drive causes a “huge” slowdown on load times then it becomes a very real drawback for that part of the process in your case (and anyone else in the same situation). I haven’t encountered this problem but this is good information for users so long as they are aware of the distinction between load performance and sample playback performance. I was exclusively addressing the latter.

    As to GPO Studio and any issues concerning it I defer to Jeff Hurchalla as I stated in my last post. I can give you no useful information on the subject. He can.

    Tom

  6. #6

    Re: GPO Studio Requires Samples on C: Drive?

    Quote Originally Posted by Tom Hopkins
    As to GPO Studio and any issues concerning it I defer to Jeff Hurchalla as I stated in my last post. I can give you no useful information on the subject.
    bmonroney is right here.

    Our .gpo files contains amongst other things, information coming from the NI VST plugins themselves, ie "VST chunks" that are proprietary, we can only save whats been given to us by the VST and reload it back after.
    Its a binary black box. We have absolutely no way of decoding that information ourselves, and its most probably illegal to even try.
    This is no "lame programmer excuse" please trust me. you could confirm with NI.

    This should really be put in a FAQ somewhere.

    Cheers
    David Viens, Plogue Art et Technologie Inc.
    Montreal. http://www.plogue.com

  7. #7

    Re: GPO Studio Requires Samples on C: Drive?

    Does it have to be the C drive or is it just limitted to the same drive that GPO itself is installed on?

  8. #8

    Re: GPO Studio Requires Samples on C: Drive?

    Quote Originally Posted by FlyingRon
    Does it have to be the C drive or is it just limitted to the same drive that GPO itself is installed on?
    No, it can be any drive you want.

    The important thing to know is that the information from the Kontakt Player
    that is saved within the .gpo files will reference the samples location
    on the current machine. The different templates included with GPO Studio
    were made on a machine with the default installation path (i.e. on the C
    drive) so that it would work for a majority of users.

    If you install the samples on another drive (through the installer, never
    manually!), the templates won't work as is, you'll have to locate each and
    every sample and re-save the .gpo file. Once this is done then the template
    will reference the samples as installed on your machine. Also keep in mind
    that if you do so, the .gpo files you produce will only work on that machine
    and any other that will have the samples installed at the same exact location

  9. #9

    Re: GPO Studio Requires Samples on C: Drive?

    Quote Originally Posted by KevinK
    Apparently, GPO Studio has been built so that it can *only* function if the samples have been installed on the C: drive.
    Kevin,
    I'll jump in here just a moment to say:

    1. I posted a (fairly obvious, I guess) workaround for the library problem in the Benchmark thread. Not really a something we should have to do, but it works.

    2. I verified that the library search routine will indeed move from drive to drive and eventually find the libraries and load them successfully. I did this on my new DAW, where I have very few files.

    I think the problem may be how Kontakt is dealing with its search that is causing the failure. I think it's not releasing memory as it scans for the files. Watch in Task Manager as a long search progresses. On a system with a huge number of files (like my old DAW), disaster strikes somewhere along the way.
    Bill

  10. #10

    Re: GPO Studio Requires Samples on C: Drive?

    seb (ma cocotte! ;o) and Bill,

    Thank you so much for shedding some actual light on the situation. If I understand you guys correctly, the problem I was having was that I am loading a .gpo file that was written on a system where the samples were installed on the C: drive. Had Bill's setup been such that his samples were on the D: drive, GPO Studio would have insisted on looking for them there, instead, because the library location is part of the opaque mass of VST state that gets passed on to the host (GPO Studio in this case) for storage. That all makes a good deal of sense, and I wonder why Tom felt the need to go on and on about how there's no real need to ever have samples anywhere but on C:.

    And yes, Bill is right, if one is patient enough, the stupid NI search routine will ultimately go from disk drive to disk drive. It's doing it on my machine even as I type. It's been doing it on my machine for 5 hours now - but that's unfair, because I haven't been available to click confirmation every time it fails to find a sample in the expected place, and it's sat waiting for me for long periods of time. Last night when I was first banging my head against this, I thought I saw it starting over and looping forever on the C: drive, but I must have been mistaken.

Go Back to forum

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •