Gigedit caveats

[dahnielson]

* It would be great if it was possible to add a dimension to all regions at once. Currently it's a bit tedious and I'm glad that the instrument I'm building now only was sampled in minor thirds and not chromatic.

* The window titled "Dimensions of selected Region" doesn't update wen I select another region, thus the title is a lie. This means I need to right click on the region after selecting it and choose "Dimensions..." from the pop-up menu. This is also somewhat tedious and may lead to confusion over what region the window is actually displaying dimension data for.

* Be able to delete all samples in a group instead just one at a time.

(I've committed the points above to the bug tracker btw.)

[dahnielson]

Ok, this is driving me nuts. I've been programming The Delicate Hollywood piano in gigedit. When I did a small test it worked. But now when I'm done all LinuxSampler do is give off this metallic noise sound for every note. First I thought it was a problem with the original samples being 32 bit float AIFF, not that it should be a problem I guess, and converted them myself to 24 bit WAV. But the problem is withstanding.

I'm giving up for today.

[dahnielson]

After using sndfile-info (what a wonderful set of tools, it's really fun to work with audio and GNU/Linux, don't know why I've waited so long to combine the two) on the AIFF I see that they apparently are 24 bit after all and it was Audacity that threw me off.

I'm making a small sample (sic) gig to demonstrate the problem.

[dahnielson]

Here's a one note example:

http://files.dahnielson.com/tmp/TDH_demo.gig.rar

It contains a single region on C3 with a velocity dimension that has eight zones (even though there are only five velocity layers, simply because you can't split it into five, the top and bottom layer use one zone while all the others use two).

The problem starts when I'm adding the velocity dimension. What am I doing wrong?

[dahnielson]

I did another note note example and noticed that everything went well until I saved it. What I did:

1.) Created a new gig in standalone gigedit.

2.) Added five samples.

3.) Added a region on C3.

4.) Added a velocity dimension split in eight zones.

5.) Saved everything to test.gig

6.) Loaded my newly created gig in LinuxSampler and opened the plugin gigedit.

7.) Added the samples to the zones.

8.) Sat the unity note for all dimension parts to C3.

9.) Made sure everything sounded fine.

10.) Saved everything, replacing test.gig

11.) Now everything sounds weird.

12.) ... ?

13.) Profit!

Is it fair to assume it's a bug?

[dahnielson]

Ok, I redid the test completely in the standalone gigedit and it works!

So, saving from live mode corrupts the gig. Good to know. Good to know.

[dahnielson]

Whoho! The "Replace All Samples in All Groups" saved the day. Replaced all the corrupt samples with the original ones. I knew such a function would come handy some day.

Now I have to tweak the velocity curve to make it less... let's say... eh... "housy".

[cuse]

Which save function in gigedit did your use exactly? Save or Save as? You have to know, those two behave completely differently. "Save" (of course) is designed to store the changes to the same file and to keep resource usage as low as possible during the save operations, it uses some tricks like moving around the chunks first in the physical file and then saving all the data to the chunk's bodys.

Save as on the other hand is simple, it really just serializes the current gig informations and writes it to the supplied file. BUT save as is currently designed for only writing to ANOTHER file. So if you use "save as" to save to the same file, you'll certainly end with corrupted data. So did you probably use "Save as" on the same file?

[dahnielson]

Yes. I used "Saved as" in the live mode gigedit and replaced the test.gig (as described above).

Didn't think of that difference. A bit more obvious when you explain it.

But, there should be some kind of prevention against this so this situation won't happen. Don't think I will be the last person to make that mistake...

[Andreas]

I could replicate the bug without using "save as". I think there is a bug in the RIFF::Save() function, I'm investigating that at the moment.