Latest GO Windows release on SF

[JLD]

I finally took the time to build latest trunk.
1726 for win32 and win64 on line on SF.
https://sourceforge.net/projects/ourorgan/files/Testing/

 

[e9925248]

I finally took the time to build latest trunk.
1726 for win32 and win64 on line on SF.

Can we get a new "stable" release in the GO 0.3 folder? 13xx is in my option too old [17xx is in my option still too new for declaring it stable and has seen to many changes - I have declard 1694 as stable for Linux].

 

[JLD]

Can we get a new "stable" release in the GO 0.3 folder? - I have declard 1694 as stable for Linux].

DONE, 1694 in stable GO 0.3 windows folder.

I will be out of building environment for some time (moving to a new computer) and might not be able to provide Windows updates short term.

JL

 

[JLD]

GO rev 1819 is available in SF "testing" folder.

 

[Ghekorg7 (Ret)]

Hi JLD, hi M

I believe you can declare now 1726 as stable, which worked superbly all those months.
I did try 1819 but encountered problems and finally returned to 1726.

1. In any attempt to change sample buffers and rate (for example was at 1024 and 96KHz wanted 128/48KHz) GO froze and then crashed after 10 min freeze.
2. In log messages window I did see that samples (from Sonus Paradisi) didn't have pitch info header (!?) and
3. Log messages sayin' in odf there is no main release on samples (I did an organ with 3 x releases main release being rel99999)

Those issues were not there with 1726. I understand that new 1819 looks for pitch info header to work perfectly on changing temperaments ect, but, afaik SP samples have never an issue on this. Also this look for pitch info will be a pita for all older sample sets and how a user can now use them without these log warnings? I mean without being a sample set producer at the same time.

Any ideas ?

 

[e9925248]

First, I would recommend GO 1821 (ASIO free builds are already available), as lossless compression had a bug.

1. In any attempt to change sample buffers and rate (for example was at 1024 and 96KHz wanted 128/48KHz) GO froze and then crashed after 10 min freeze.

Couldn't you just have hit one of the from time to time reported hangs (like http://www.magle.dk/music-forums/19816-sound-issues-upgrading-go3.html )?

Such a hang indicatetes, that opening/closing of the sound driver hangs (which might even be related to the specific GO audio backend, you use).

2. In log messages window I did see that samples (from Sonus Paradisi) didn't have pitch info header (!?) and

Strict ODF mode got new checks for temperament bugs, as people seem to have trouble getting it correct. The message is shown, if the main wav of a pipe does not embedded a pitch information and there is also no override of the pitch via Pipe999MIDIKey and Pipe999PitchCorrection.
Note: The pitch information should contain the sounding pitch, not midi key number of the keyboard (key 36 of 4' stop should contain something around 48). GO uses the pitch for other purposes too.

3. Log messages sayin' in odf there is no main release on samples (I did an organ with 3 x releases main release being rel99999)

You have got very likely specified a finite XXXMaxKeyPressTime for all releases, so if you keep a key pressed long enough, GO will not find a suitable release any more (play the pipe for 2 minutes). You need at least one with XXXMaxKeyPressTime=-1 (which is also the default).

 

[Ghekorg7 (Ret)]

Thanks Martin

1. I see 1825-46 only, I'll get it after this.
2. The reported hangs page is not found :-( , but didn't had any issue like this with GO 0.3.1.x previously up to 1726
3. I insist on pitch info warning message. The samples are from SP latest demo set (just flute 8', 4' & 2') and work perfectly with 1726 any temperament and pitch.
4. In any case, yes, Pipe999MIDIKey= is at help and essential for many cases (as I did on Balzan's keyboard noise rank/stop) BUT, it has to be added on thousands older sample sets' pipes in the odf and there are a lot sample sets for GO today....
5. xxxMaxKeyPressTime. To tell you the truth when multi release function was available for GO at rel99999 I did set -1. Then I started to see that many users/creators did set xxxMaxKeyPressTime=99999 and I followed. Indeed -1 is the correct setting for this. I must now correct all my odf replacing =99999 with =-1 ..... omg they are too many !

On my main GO computer (win8 x64, i7 IvyBridge 2.4GHz, SSD128, 16GB ram DDR3, Realtek with Asio4all 4.11) I'm keeping 1726 for now as I have Two main big sets I created and using live accompanying (and soloing) a church choir in gigs outside the church and cannot spend time updating odf. By the way I do not use lossless compression on this, there is no need for. Ram load is about 10GB and it is loaded at about 7 to 10 seconds.

I still think that 1726 can be declared stable for windows )))))) I'll test 1825-46 on my other computer (win7 x64)

 

[MikeL]

Dear all,

Long term user but lurker of GO here - I have the usual free sets including the HW ones, plus a couple of commercial sets that I have converted. I've only got the HW demo which I use to help with conversions, but I must say that, apart from the tremulants (which I'm not that keen on anyway) there is practically no visual or audible difference now (although I've never heard the HW windmodel in action). Many thanks to all concerned both for the software and the samplesets.

I've just upgraded to 1819 (win64) and I'm getting a mountain of odf strict warnings

- almost all are 'non-portable directory separator /' - GO has always accepted both '/' and '\' - are we supposed to standardise on one or the other. I'm not sure that I see the reasoning here as to why one is less portable than the other. I tend to use '/' because its a bit less of a pain in shell scripts so my ODFs are full of them.

- a few 'no pitch information provided' - these are almost all keyboard & stop noises. Presumably we don't want GO to try and retune them! What is the correct setting for these?

- A handful of 'would retune be more than 600 cents/' : nothing special about these in the ODF: perhaps genuinely need attention?


Regards

Mike

 

[L.Palo]

Hi!

The directory separator is a battle I lost. I wanted to use / instead of \ or at least keep the both and silently fix things internally (as it actually does anyway). The thing might be a line in the help files stating that \ is the separator to use. Well, it's no big thing use search and replace and that problem is gone.

Something to think about for Martin, a pitch information value of MidiNote 0 and PitchFraction 0 is valid (actually it denotes a 64' low C) but means generally - don't try to pitch shift this sample (unless the ignore pitch info in files is checked). There should be no log warnings for this. Also an effect stop should not have any HarmonicNumber in the odf and it's perfectly ok as it generally is meaningless in that context.

The re-tuning to more than 600 cent is also superfluous in my opinion, but the more a note is stretched by resampling the more artefacts will also appear. GO allows 1200, and I don't think we should bother with anything below as it's ok with the functionality.

Kind regards

Lars P

 

[MikeL]

Hi Lars,

Thanks for the suggestions. As you say, the directory separator issue is just a minor annoyance and easily dealt with. I tried setting Pipe999MIDIKeyNumber=0 for the effects pipes, but I still get all the false positives - I presume you are talking about the .wav header fields here. This is a bit unfortunate - real problems will get lost in the noise here.

Another somewhat related question if I may: how can we specify the diapason of the instrument? When I select a temperament it seems to transpose the whole instrument to A=440 rather than retain the original pitch.


Mike

 

[L.Palo]

It's intentional that the default re-tuning will be to a1=440 as it's actually the baseline reference. If you wish to have another pitch there are different ways to do it but the one that will keep the temperament correct is to specify the offset of the whole organ on the Master Controls panel. Lets say that you have an organ recorded at choir tone pitch a1=467, if you want to have this organ at the original pitch but with different temperaments (than original) then you must compensate +100 cent on the Master Controls panel. If you only transpose the temperaments will not be correct in relation to the keys anymore.

Kind regards

Lars P

 

[e9925248]

Strict mode is intended as developer mode. It gets new warning, as new suboptimal ODF styles show up. It should lead the GO users to clean, correct ODF, so it might seem that GO strict mode is nit picking.

GO uses the pitch information for other purposes (eg. for selecting the cross-fade parameters) - in my option, this data will also be usefull for other things in the future. MidiNote 0 and PitchFraction 0 includes no pitch information, so a 2' would be handled like a 16'. Therefore GO reports this.

For a recording of a real 64', I doubt, that the lowest note will be 100% in tune and more like PitchFraction 0.000XXX. The warning of an ODF override of this still needs a correction.

For the stop noise, I use Pipe999MIDIKeyNumber=36 in the demo ODF, as this is the lowest key number of the corresponding manual. For keyboard/pedal noise, I would use the corresponding keyboard midi note number.

 

[e9925248]

1. I see 1825-46 only, I'll get it after this.

I refer to the minimum required GO version, so 1825 includes the changes.

2. The reported hangs page is not found :-( , but didn't had any issue like this with GO 0.3.1.x previously up to 1726

Remove the ) from the end of the link.
The problem description looks like: Somebody, who didn't have any GO issues has a hang after an GO upgrade. After removing the old global settings (GrandOrgueConfig), GO is working again.

3. I insist on pitch info warning message. The samples are from SP latest demo set (just flute 8', 4' & 2') and work perfectly with 1726 any temperament and pitch.
4. In any case, yes, Pipe999MIDIKey= is at help and essential for many cases (as I did on Balzan's keyboard noise rank/stop) BUT, it has to be added on thousands older sample sets' pipes in the odf and there are a lot sample sets for GO today....

See my comments at my previous post.

 

[e9925248]

Something to think about for Martin, a pitch information value of MidiNote 0 and PitchFraction 0 is valid (actually it denotes a 64' low C) but means generally - don't try to pitch shift this sample (unless the ignore pitch info in files is checked). There should be no log warnings for this. Also an effect stop should not have any HarmonicNumber in the odf and it's perfectly ok as it generally is meaningless in that context.

MidiNote 0 and PitchFraction 0 has always had the meaning no pitch, as we wanted to handle non-annotated samplesets. I'll fix GO, so that you can specifiy MidiNote 0 and PitchFraction 0 via ODF without any warning.

Effect stops are currently also retuned, so warning about missing retune settings are logical. If we don't want specifiying these settings, I would suggest Pipe999NoTemperamentRetune=N. As we are using the sounding pitch for audio processing, I'm not sure, if we should allow a missing pitch information in the sample.

The re-tuning to more than 600 cent is also superfluous in my opinion, but the more a note is stretched by resampling the more artefacts will also appear. GO allows 1200, and I don't think we should bother with anything below as it's ok with the functionality.

GO reports the retuning relative to the original pitch setting of the organ. > 1200 cent as error, > 600 cent as warning. Are you aware of any organs, where the basepitch is >= 600 cent away from 400Hz - if not, it will only report broken temperament settings.
Smaller pitch differences could be OK, the ODF creator still has to check, that equal temperaments sounds correct.

 

[L.Palo]

I think we should allow ranks/stops to not be retuned (the use case is sound effects mainly, often without any "intentional" pitch). If we do it by adding a parameter or not is a choice we must make. I think that using for instance HarmonicNumber=0 could be one way of dealing with the retuning without adding new parameter line, but if a new parameter is added it should be for whole rank as well as at pipe level, I think. Also if it's specified that a sample is a sound effect all pitch info in the file should be ignored and no warning/error logged.

The re-tuning is mostly annoying for interpolated notes when (like in the demo sampleset) not all samples are available individually for every pipe. No organ I'm aware of differ so extremely much from the general standard of a1=440 Hz. A rare few I've heard of are up to a third lower and many historical instruments are higher by a semi tone. I think that since we allow up to 1200 in GO we shouldn't fuss about it either.

Kind regards

Lars P

 

[e9925248]

I think we should allow ranks/stops to not be retuned (the use case is sound effects mainly, often without any "intentional" pitch). If we do it by adding a parameter or not is a choice we must make. I think that using for instance HarmonicNumber=0 could be one way of dealing with the retuning without adding new parameter line, but if a new parameter is added it should be for whole rank as well as at pipe level, I think. Also if it's specified that a sample is a sound effect all pitch info in the file should be ignored and no warning/error logged.

Misusing a setting for something different is usually a bad idea, especially as the pitch information could be useable for sound filtering some time in the future.

The re-tuning is mostly annoying for interpolated notes when (like in the demo sampleset) not all samples are available individually for every pipe. No organ I'm aware of differ so extremely much from the general standard of a1=440 Hz. A rare few I've heard of are up to a third lower and many historical instruments are higher by a semi tone. I think that since we allow up to 1200 in GO we shouldn't fuss about it either.

So the 600 offset is save.

Reading your answer, I'm not totally sure, if you have understood, how the check works. The check does not care for the tone quality issues caused by a large pitch shift. It compares the pitch difference between original and equal temperament setting with 600. Even if somebody would use one sample for 4 octaves (GO allows +/-2400 by combining two settings),he can write a correct ODF, which will not print any warning.

 

[MikeL]

Having spent a few minutes on my previously converted ODFs I found the new warnings useful (once I got rid of the hundreds of effect stop warnings). Just one or two individual pipes turned up a '600' warning, and, sure enough, there was an error in the wav header and they went wrong following application of a temperament. It would have taken me ages to notice them, then figure out what the problem was without the warning.

For what its worth, I agree with Lars that a parameter in [Rank999] that declares an effect stop not for retuning would be more elegant and loss verbose.

For the retuning generally, are you against having something like Diapason=999 (in Hz) in [Organ]? As Lars explained, it can be set in the master panel, but to me it seems a natural part of the overall specification of the instrument. Setting it in master also is not consistent between retuned and native.


Shifting the topic slightly, the warnings for [Label999] are a bit inconsistent with the others: if NumberOfLabels in [Organ] exceeds the number of labels declared, or if a label is missing from the sequence, there is no warning and GO draws a large ugly white blob at approx 0 0. It took me quite a lot of trial and error to find the mistake in my ODF!


Mike

 

[L.Palo]

Even if somebody would use one sample for 4 octaves (GO allows +/-2400 by combining two settings),he can write a correct ODF, which will not print any warning.

Was it something like in the attached ODF you had in mind or was it something else that I've missed? Place it in Bureå Gravkapell (Bureå funeral chapel) sampleset to load.

Kind regards

Lars P

 

[e9925248]

It would have taken me ages to notice them, then figure out what the problem was without the warning.

This was the intention behind these warnings. Please note, that the check can't notice small errors. You still have to play for each stop each pipe with equal temperament to catch them.

Shifting the topic slightly, the warnings for [Label999] are a bit inconsistent with the others: if NumberOfLabels in [Organ] exceeds the number of labels declared, or if a label is missing from the sequence, there is no warning and GO draws a large ugly white blob at approx 0 0. It took me quite a lot of trial and error to find the mistake in my ODF!

A label (in the old panel format) has lots of settings with a default value, so GO is not missing anything.
If you use the new panel format (Look at our demo organ or add to section [Panel000] NumberOfGUIElements=<any number> and look at the GO error messages), a label with an empty section is not possible any more.

 

[e9925248]

Was it something like in the attached ODF you had in mind or was it something else that I've missed?

Exactly, what I meant.