Instrument #'s

[Jamieh]

I had a .gsp file saved with all of my orchestral instruments in it. I decided to go back through and unload some of the instruments I don\'t use to free up some memory. But when I saved and reloaded my new setup, the old instrument numbers were not preserved. Anywhere I had removed an instrument, all the other instruments below that point slid up a number.

Is there any way to restructure .gsp files and preserve the instrument numbers? I am doing multiple patch assignments that depend on these numbers, and I really don\'t want to have to go through my work and reassign all the numbers every time I decide to make a change to my base orchestra setup. I guess the best solution is to build a .gsp will all the instruments I will need before I start, but that means that if I change my mind at all, I may have to go through and restructure my patch numbers.

Any suggestions? Thanks.

[ursatz]

I\'d like to know if there\'s an answer to this one, too. It would be a big convenience if I had a way to assign instrument numbers that wouldn\'t vary.

[Bill]

If the patch number of the instrument is available, it will get that number; if not, GS will assign an available number. Many libraries give each instrument patch number 0, so they’re always assigned a different number when loaded.

So… do some planning, then edit all the instruments you use on a regular basis and assign them a patch number.

[Simon Ravn]

I have always considered this a big problem with Giga. I also pointed it out here on the forum 10 times at least. If there was just an option to replace an instrument with either an empty one done by yourself or simply an ´unload and keep empty´ option it would be fine, but no.. You can just never delete instruments from your performance, so sometimes I end up with maybe 30 samples I am not using but I just have to keep them inthere not to screw up everything!

[Georg]

I also think this behaviour can\'t be the solution. The only right way is, that the user can give free program numbers and he must have the possibility to change them. The >loading performance< features must also be changed in a more variable feature and the presets shouldn\'t be linked with program changes! Maybe a part of a solution for nemesys: changing the performs/gsp files in a simple text file, which can be edit by anyone. The data base and the (endless) scanning is also a very hot problem for me. I have often a very high change of waves on my harddrives (sometimes between 1000 and 10000 or more per day), I don\'t need this feature, because I know where my files are and I also don\'t need a data base of waves in GigaStudio. But I\'m sure, nemesys will have some ideas.
By the way I\'m lucky with a lot of new GigaStudio features, like saving program data separately.

I think Bills idea is the best for the moment.

Georg

[Bill]

> I have always considered this a big problem with Giga...

Well… Same suggestion as above…

If your instruments have unique patch numbers, they won’t change when loading or unloading other instruments.

[This message has been edited by Bill (edited 01-29-2001).]

[Jamieh]

Georg--the new update to GigaStudio lets you tell quicksound to ignore .wav files when it is updating the DB. That should save you some time.

So Bill, I can go into the editor and assign instrument numbers to my samples? That might be the answer--I will go in and assign hard coded numbers to the patches I always use.

It would be MUCH easier if GigaStudio allowed you to set and save Instrument #\'s with a performance. That way every time you loaded the performance back, the patches would be on the same instrument # regardless of what patches you unloaded. This seems like a trivial thing to add to a new version.

[food4thought]

There are, unfortunately, a lot of shortcomings with the way GSt handles instruments. Besides the numbering problem you guys mentioned here, there another one I find equally frustrating....

If the location of a GIG file changes on the HD, next time you load a performance that requires it... GSt will not load it, not look for it, and will certainly not tell you about it. Furthermore, there is no (easy) way to find out where GSt expected to find the instruments in the first place so that you could at least undo the damage. Therefore, trying to better organize your sounds on the HD when you have GSt projects going is a bad idea.

This I consider to be a rather serious issue, but it does not require a lot of effort to be sorted out.

I have more in mind but they\'re minor issues or ideas in order to improve functionality in this field. Just fix that one out. Hope the upcoming v2.2 offers big improvements.

[Georg]

Oh, thanks for the tip, Jamieh, I haven\'t noticed that update.

[Simon Ravn]

food4thought, that is not entirely true. Yes if you move them and GS doesn\'t \'notice\' and updates its database, the samples will not be found. But you can just do an UPDATE on the Quicksound database (it\'ll take some time though) and the samples will then be found. Actually that is one of the nice features of Gstudio IMHO, that you can just move your samples around without problems.

[Chadwick]

Simon, is that for real?

Are you saying that if I save my \'Toy Orch\' performance which utilises my \'Squeezy Trompet\' sound which comes from folder A, then move that sound to folder B, that all I have to do is run a Quicksound update and when I next load \'Toy Orch\' it will automatically load \'Squeezy Trompet\' from folder B instead of trying to get it from folder A?

That\'s amazing!

How can such a clever feature exist in Giga, but still no VCF envelope amount control or user defined velocity curves ???