Looping issue

[jefferycrowley]

Hello all,

I have a problem with a sample set that I have created with samples from the Marcussen Organ formerly in Moerdijk. It is mimicking the real Casavant that I will be playing as organist. It is all mechanical and only 13 ranks, so I needed to make it as real as possible.

There is a problem with the original Sample set and the Hoodeverk Principal 8' low C (036-C.wav) has markers incorrectly in the wav file. I have been able to fix this with other sample-sets that I have created in the past. Normally I use Lars Palo's Loop Auditioneer to remove all loops and markers>save the file then re-load the file/folder and reloop the wav file and add a release marker to it> then save the file again. I strip the pipes from the stop using GOODF.exe>re-load the samples into the ODF and save it.

Grand Orgue writes the file and when I open the organ and test the note it is as if I have done nothing to fix the issue. I have even deleted the cache file for the organ and re-build it as well as forcing strict reading of the ODF upon loading. Nothing will fix this issue. I have even tried to replace the wav file with a known good example just to test it and it does not work. Curses to myself for not fixing this in the original HW ver 2 of the note for this stop. I have even attempted to use the Kontakt original version which I have the disc for since maybe 1992?

[larspalo]

@jefferycrowley You're absolutely sure that the sample file is fixed and play correctly in LoopAuditioneer and saved back (modified) to the right location? Cache in GO is removed and disabled to ensure clean reading of the organ file? You're also sure that the paths for the pipe really point to the changed file and not somewhere else? What errors or warnings are displayed?

As the sample file likely is proprietary, it shouldn't be distributed widely, but I'd very much like to inspect it for testing purposes if it would be possible.

[jefferycrowley]

Hello Lars, I have attached the file for your inspection. It is note 036-C of the Prestant 8' I downloaded and installed Loop Auditioneer 0.9.82, because I was using the previous version and I did not know that there was a newer version, but still I got the same results in Grand Orgue. The New loops should number 7 with the release.   In the original version 2 (for HW2) the lowest note 036-C for the HV Prestant had two release markers one at the beginning of the file and one at the extreme end (after the reverberation has died down) and no loops.  Loop Auditioneer has found at least 14 very good loops, but I just saved 7 of them along with a new release marker. I will attempt to put together a one stop version of Grand Orgue to see there is some other issue. I did have an issue with GOODF.exe when creating another organ where the manuals all are 56 notes (except the pedal) and GOODF.exe kept placing 73 notes for one of the manuals even though in the interface for the manual I have 56 keys chosen from the spinner window (I did type the number directly into the window) and had to correct the issue manually by editing the ODF directly via Notepad. I no longer have that issue since when you open the ODF again for editing it reads the information directly from the .organ file. Thank you for creating GOODF.exe.  It is very intuitive to use (If you already know how the organ database is organized and created).   Now if someone would do the same for Hauptwerk.   They have promised a graphic, comprehensive interface to assist with the sample-set creation since the Crummhorn Lab days.  That was almost 20 years ago and nothing has been created (or at least of what I know- there may be something in existence, but if you are not in the "club" of sample-set producers for Hauptwerk, you are not privy to such a beast! Good job also on the Bygdsiljurn Church presentation.   Very realistic.    I had my mind set upon being a sample-set producer at the very beginning of Hauptwerk and almost had Old St. Patrick's Cathedral in New York City in my pocket because I knew the Great Granddaughter of Henry Erben - whose extant 3 Manual Organ is in that Church - Never touched by an "upgrader".   The organ back in the 1990's was not yet restored and had many wind leaks and a completely exposed organ console.   Someone walked off with all of the side and back paneling years ago.   Then I moved back to Wisconsin.    I have kept abreast of Grand Orgue and am very happy that the whole organization is moving forward in a positive manner by making the application not so ancient!   ASIO is such a welcome feature and my latency has gone to nearly nothing and it now is pleasant to play a GO organ.  I have been working on getting a large Austin Organ in a local Church sampled before they replace it with a huge Taylor and Boody 3 Manual Mechanical Action Instrument.   The Austin went into the church in 1965 and I remember it being installed there.  I want to sample this instrument solely for Grand Orgue.  There are no representative instruments in Grand Orgue or Hauptwerk or Sweelinq for the American Builder.  Sure you have a dozen or so Æoline Skinner, E.M. Skinner instruments to choose from, but I hate the sound of these instruments.  They always were installed in locations that were "acoustically challenged" i.e. dry, dry, dry.    There is a whole organ world waiting to get American Builders represented.   This Austin is a beauty and was installed in a "gothic" styled Lutheran Church that had just dampened any reverberation with cellulose acoustic tiles.    Over the years they have replaced porous plaster, acoustic tiles and carpet with hard surfaces everywhere and the organ just bloomed.   Austin was also not into the "Orgelbewegünen" movement and sort-of did their own "thing"  so the important instruments were well balanced.   It was supposed to have casework finished to complete the installation, but the church ran out of money.   The only good thing is that there was a great little organbuilder from the area that added only a few stops which blended in very well and completed the whole instrument.   This same organbuilder also got an extant 2 Manual J.W Steere from 1893 completely restored and sounding wonderful AND a beautiful Bedient Portative Organ with 3 ranks. The sad part of recording American Instruments is money.   All these places want a large sum of money to be able to record or the Organbuilders will deny the request.   I know the past and present organists of this church, so it will be a challange and difficult to record because the place is huge and on a busy main road in town and near the Hospitals so there are always sirens.   I only have until next year to do this so hopefully I will be successful. Thanks, Jeffery C. Rowley on Monday, January 8, 2024 at 04:10:21 AM CST, larspalo ***@***.***> wrote: @jefferycrowley You're absolutely sure that the sample file is fixed and play correctly in LoopAuditioneer and saved back (modified) to the right location? Cache in GO is removed and disabled to ensure clean reading of the organ file? You're also sure that the paths for the pipe really point to the changed file and not somewhere else? What errors or warnings are displayed? As the sample file likely is proprietary, it shouldn't be distributed widely, but I'd very much like to inspect it for testing purposes if it would be possible. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[eturpault]

had to correct the issue manually by editing the ODF directly via Notepad.

Such a manual editing can be done with OdfEdit as well 😆.

[jefferycrowley]

Thank you for responding Eric, I know that I could have used OdfEdit as well, but it only takes me a couple of seconds to directly edit the ODF. On Tuesday, January 9, 2024 at 04:04:37 PM CST, Eric Turpault ***@***.***> wrote: had to correct the issue manually by editing the ODF directly via Notepad. Such a manual editing can be done with OdfEdit as well 😆. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jefferycrowley]

Hello Lars, I encountered the mis-matched key issue with GOODF.exe again.   When I attempted to create just an organ from scratch using GOODF.exe to test the one pipe/stop.    I created an organ with just one manual with 56 keys. I double-checked in GOODF.exe the Manual setup had 56 keys.  The Stop has 56 notes or *.wav files.  I used the 036-C.wav file that I sent to you previously. I wrote the ODF File to the directory and attempted to launch the .organ file that I just created and got a hard stop in Grand Orgue stating Element 002 in Panel 000 had an out-of-bounds error.   When I viewed the .organ file in notepad - Indeed the First instance of Manual [Manual001] in the ODF had NumberOfLogicalKeys=56 also NumberOfAccessibleKeys=56.  The stop had NumberOfAccessiblePipes=56;  NumberOfLogicalPipes=56.  The GOODF.exe interface had showing in the GUI section of Main Panel for the Hauptwerk manual using 56 keys displayed in the spinner - but written in the Panel 000 or the main Panel in the .organ file showing [Panel000Element002] as such: [Panel000Image001]Image=Images\Console\CLC-Casavant - Main Panel.png [Panel000Element001]Type=SwitchSwitch=001PositionX=431PositionY=363ImageOn=Images\MP Stops\CLC Prestant 8 Test ON.pngImageOff=Images\MP Stops\CLC Prestant 8 Test OFF.pngMouseRadius=0TextBreakWidth=0 [Panel000Element002]Type=ManualManual=001DispKeyColourInverted=YDispImageNum=2DisplayKeys=61 --------------------------------- If I open the ODF using GOODF again, it loads correctly - and saves correctly. This is the same issue that I had with another 2 manual instrument that had only 54 note keybeds.   One key bed written correctly in GOODF in both the Manual Section, with each manual stop with 54 notes, and the GUI instance of Manual-Grand Orgue having 54 keys correctly in GOODF, but writing the actual .organ file on the primary manual 61 keys and again giving me a hard stop loading the instrument on the same Element in Panel 001 as 73 keys.   I never even typed that into the GOODF interface or used the spinner to count up to that number.    Again, I edited it in Notepad and then re-opened the organ file in GOODF, where it read the data correctly and subsequently wrote the new ODF correctly. Also, with this experiment I was able to load the one stop Prestant 8' using the same directory as the previous instrument and had no issues with 036-C reading the file incorrectly and it behaved normally.   I guess that I will have to re-write the entire instrument using this good ODF. Thank you, Jeffery C. Rowley  On Monday, January 8, 2024 at 04:10:21 AM CST, larspalo ***@***.***> wrote: @jefferycrowley You're absolutely sure that the sample file is fixed and play correctly in LoopAuditioneer and saved back (modified) to the right location? Cache in GO is removed and disabled to ensure clean reading of the organ file? You're also sure that the paths for the pipe really point to the changed file and not somewhere else? What errors or warnings are displayed? As the sample file likely is proprietary, it shouldn't be distributed widely, but I'd very much like to inspect it for testing purposes if it would be possible. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[larspalo]

@jefferycrowley Thanks for reporting, I couldn't find any attached sample file though to test. Perhaps try a private mail to me (one could find it in any source file header like for instance https://github.com/larspalo/GOODF/blob/master/src/Attack.cpp)

I'm very much interested in the key number mismatch of GOODF issue, though, so that it could be fixed. Can you recall the circumstances for when it occurred so that it could be reproduced and any bug tracked down. A few questions to help narrow it down, and help me understand the situation better, are:

• You did start with a new empty organ in GOODF and not one that you modifed?
• Was the number of keys set correctly in the Manual before the GUI element was created or was it changed afterwards? (The order of changes might be important to trigger this. Ie. was the Manual first at the default 61 keys, a GUI element created for it, then a change to the manual was done)
• As I understand it, a correct odf will also be displayed correctly and (re)written correctly by GOODF? (the issue only happen with the first writing)
• The main issue is that too many display keys are written for the GUI element of the manual on the panel, right?
• What exact version of GOODF are you using? In November 2023 I did commit a fix for the manual key numbers on the panels, and it should be included in the 0.9+ versions.

I wish you all the best with your sampling projects! It's certainly lots of work, but it's also quite rewarding.

[jefferycrowley]

Lars, This happened in GOODF.exe on a new clean database on the initial Save operation.   I am using version 0.8 so I downloaded the newest version from GitHub.   When I start a new instrument I begin by adding the Keyboards >Pedal first etc. I completely setup the Keyboards via the interface.   Then I add the Stops and Couplers if applicable.  then I add the Windchests, then the Tremulants and Enclosures when applicable..  Finally adding the Ranks and Switches.  then I edit the Stops and add the actual stops at least in name and formatting.   I add the Sample files after i have everything else setup correctly.     The issue with the number of keys for a manual is usually on the first hand manual/keyboard.   Even though the spinner window provided for input has the correct amount of keys/pipes in every location.    I finally setup a rough Main Panel using the provided AutoDraw elements.- then I write the .organ file.   I attempt to launch the organ.   this is usually where the hard stop occurs.  I see that the newer GOODF.exe fixes some issues with the number of keys/pipes is fixed so maybe I won't have the problem moving forward.  It was easy enough to edit the ODF manually.   You software is corrected when one attempts to reload the organ file for further editing. Thanks! On Wednesday, January 10, 2024 at 04:08:48 AM CST, larspalo ***@***.***> wrote: @jefferycrowley Thanks for reporting, I couldn't find any attached sample file though to test. Perhaps try a private mail to me (one could find it in any source file header like for instance https://github.com/larspalo/GOODF/blob/master/src/Attack.cpp) I'm very much interested in the key number mismatch of GOODF issue, though, so that it could be fixed. Can you recall the circumstances for when it occurred so that it could be reproduced and any bug tracked down. A few questions to help narrow it down, and help me understand the situation better, are: - You did start with a new empty organ in GOODF and not one that you modifed? - Was the number of keys set correctly in the Manual before the GUI element was created or was it changed afterwards? (The order of changes might be important to trigger this. Ie. was the Manual first at the default 61 keys, a GUI element created for it, then a change to the manual was done) - As I understand it, a correct odf will also be displayed correctly and (re)written correctly by GOODF? (the issue only happen with the first writing) - The main issue is that too many display keys are written for the GUI element of the manual on the panel, right? - What exact version of GOODF are you using? In November 2023 I did commit a fix for the manual key numbers on the panels, and it should be included in the 0.9+ versions. I wish you all the best with your sampling projects! It's certainly lots of work, but it's also quite rewarding. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[larspalo]

@jefferycrowley If you encounter the issue with the new version of GOODF, please report that.

[jefferycrowley]

Will do. On Thursday, January 11, 2024 at 12:38:04 PM CST, larspalo ***@***.***> wrote: @jefferycrowley If you encounter the issue with the new version of GOODF, please report that. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>