I’ve had an ongoing problem for a couple of months now that doesn’t seem to be resolving itself. It’s been on another thread but I thought I’d revisit again with a new thread. I have had several attempts at creating a monster gigfile so that I can play to the crowd by selecting songs at random as the mood requires,
I have 20 setlists containing 20 songs each and have been trying to import them into a monster gigfile of 400+ songs. All sort of problems have been arising during the importing - such as:
Some imported rackspaces have the “Assign program change number” unticked even though it was ticked when exported
I have tried imported the 400 in one go, but GP never gets past half way before it freezes then crashes
I have tried importing by alphabet groups and this works ok at the start, but about halfway (around about the M or N’s) the freezing and crashing happens again.
The bass vsts (UJam) I use loose the latch feature and the interface becomes uneditable i.e. mouse clicking on the edit doesn’t work and they act as greyed out. Surprisingly, If I export from the monster gigfile and then import that into a new gigfile, the bass vst comes right and I can edit again,
I have been working on this since September and have deleted several attempts at building this monster gigfile that have failed every time.
I seems to me that there is a fault in the GP import mechanism that only becomes apparent when trying to import large numbers of rackspaces.
I am at my wits end over this. While my setlists work fine for an hours playing, I still want to have the option of a large gigfile that will allow me to choose songs at random. Is there anyting else I can do to make this work?
(A) Do you have a crash report?
(B) Can you run task manager while doing this and monitor the amount of RAM that is being used. I’m wondering whether, in spite predictive loading, you’re actually running out of memory
Also. Do you have adequate free disk space? I have noticed that if my disk is near full, GP will partially load, then crash-similar to what you are seeing.
It is relevant. GP needs free disk space as a buffer. GP will crash every time for me with the same setlist if I don’t have a couple of gigs of free space.
If you have 46GB free space then that is not the issue.
I meant it’s irrelevant with respect to the question I asked, which was how much RAM was being used.
The only time GP might need a lot of disk space is if one of the plugins is stupid enough to store samples as part of its state, in which case a huge gigfile could be created.
I took my time yesterday and managed to import all the required rack spaces without a freeze and without a crash. I saved and rebooted several times whilst doing this. At present, I’m going through the 400+ rack spaces and re-setting the program change numbers (GP does not maintain these). I hope to be back on to editing later today so will know if any Ujam non-editing problems are still there.
Sorry. Here it is.
Started at 2.9 (17%) and peaked about 1/2 way through loading at 6.1 (38%). My Surface has 16gig (15.9 available). When the gig is fully loaded, GP has used 6.1gig 38%.
I decided to blitz the Win installation and rebuild the computer, Problem solved. Its just a Windows thing. Everything can be running perfectly except for one tiny thing - in my case faults in one vst when importing. I’ve had this before with Windows and a complete rebuild is the only answer. I guess I did well to get six months from the last build.
There is no good reason to have to rebuild Windows as frequently as you have been. I’ve been building PC’s with Windows as long as there’s been Windows, and while system corruption can happen to the point of needing a fresh rebuild, that should take many years----not six months.
Either there’s a problem with the physical hardware (RAM, Motherboard, Hard Drive etc) leading to system corruption, or there is troublesome software that is corrupting your Windows installation. Considering how much you want to do with your setup, I would seriously recommend rooting out the source of the corruption issues.
Ok, point taken. I don’t usually want to rebuild anyway, but with my limited experience I tend to blame Windows. It seems in this case I was wrong anyway as when I imported a previously exported rackspace into the monster gig, the Ujam bass played up as before with a lot of the previously saved parts of not saved. I then experimented with a new blank gigfile and imported the same rackspace into that, and it worked fine. That seems to indicate to me that there is a problem with importing rack spaces into GP as the number of rack spaces gets larger. If GP imports a single rackspace into a new gigfile without problems, why will it not import the same rackspace as number 400 when there are 399 others already there?
This is driving me nuts.I worked a bit longer on a rackspace that was contained in a gigfile of 20 songs. All working well. I exported the same rackspace and then imported it into a gigfile of 400 songs. Once again, the following happened with the Ujam bass vst:
Latch was off
I could not edit anything on the bass edit page. Nothing responded to my mouse clicks.
The vst would not respond to any midi message at all. The edit page was totally dead.
I then exported the same rackspace from the 400 rackspace gigfile and then imported it into a blank gigfile. Hey presto - the bass vst was ok again. I can’t figure this at all. I have contacted the Ujam people and that say their vst is working fine.
Does anyone else have large gigfile? Is there any point in sending 400 rack spaces for someone else to test? If you didn’t have the same vsts I guess that would be pointless. I’m at a loss here as to what to do next. As stated earlier, I been trying build this large rackspace since September having had at least 5 or 6 attempts at it. Please don’t tell me that I don’t need a large rack space - I’ve already explained why I am trying to do this. Final thought - have I reached the limit of GP’s ability?
I need to stress that all the basses work as expected in the 20 rackspace gigfiles I use. It’s only when the rack spaces are exported and then combined into a big gigfile that problems occur.
Ujam have four basses, namely Dandy, Mello, Royal and Rowdy. I went through a few of the rack spaces after they were imported into the big rack file and they all had parts that would not respond, but were not all the same. No single one of the four worked properly.