Replies: 13 comments 50 replies
-
|
Kindly expand this for a Ubuntu user who is not experienced in compiling and so ;-) //most humbly ... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a plenty @larspalo . Will try that. |
Beta Was this translation helpful? Give feedback.
-
|
@eturpault I've submitted the executable to virustotal.com testing and nothing is reported. The sha256sum of the whole zip archive and the .exe file:
Here are some screenshots from the testing. After the compilation by use of cmake the only thing done is cpack for packaging, and since my original file and the downloaded one match their sha-256 nothing can have happened in the upload either. I'm leaning towards that it's a false positive you're experiencing, but if someone knows better - please inform me! |
Beta Was this translation helpful? Give feedback.
-
|
I eventually found the binaries ;-) |
Beta Was this translation helpful? Give feedback.
-
|
@jason-barba Opening existing .organ files is unfortunately not implemented yet. I'm going to begin working on that soon! Be patient, and try out all the things that can be done with this version. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @larspalo for the checks. Strangely today I launched again GOODF.exe and Windows doesn't complain about a trojan and lets GOODF to start without issue. |
Beta Was this translation helpful? Give feedback.
-
|
I have played with this software running linux and have the following comments |
Beta Was this translation helpful? Give feedback.
-
|
I can see the basic outline from your help directory. I will probably get started using Libre office, submit for review, and export to html later, since my background is only in embedded programming and engineering documentation. I assume you want separate pages for each of your major headings, and that additional pages will be added as we go along. Please correct my understanding if this is wrong. |
Beta Was this translation helpful? Give feedback.
-
|
@davidgritter You're absolutely right. It's likely that one need a general overview of the odf creation process but also specific pages for each major subject/object (especially where there are not so obvious features that can be used). We add html pages and entries to the index/content files as needed. But if you feel more comfortable with it, plain text files will be perfectly ok to begin with as it's easy to convert them into html documents. I'll try to work on the odf parsing myself for now so that one can continue working on an .organ file anytime and not be limited to just creating new ones. |
Beta Was this translation helpful? Give feedback.
-
|
I have been working on documentation and trying different scenarios, and I have found the following problems: I have not found a way to set a Unison Off coupler I have not been able to import by midi note from all sample sets. For example, the Augustine organs Kassel-Niederzwahren sample set names the wav files 36.wav, 37.wav, 38.wav ... Is this an error, or do we need to include rules on what file names are acceptable? |
Beta Was this translation helpful? Give feedback.
-
|
@davidgritter Thanks for reporting the issues. I'll add the Unison Off option on the coupler panel, it's already available in the backend coupler but not visible to the user on the panel at the moment. I'll see if it's a very easy fix to alter the detect by MIDI number to handle both the 036 and 36 cases. |
Beta Was this translation helpful? Give feedback.
-
|
@davidgritter I've committed changes that should fix both issues above. For future work I think that all issues should be opened at https://github.com/larspalo/GOODF/issues so that we keep the noise level down in this discussion thread. I also opened the discussion option on https://github.com/larspalo/GOODF/discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Can I add another plea for implementation of reading existing ODF's. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent! Is that in github? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, my commits (the code) are already available on GitHub. The new release (v0.4.3 if you don't build it yourself) is still processing, but it should be ready in about 15 minutes more or so. |
Beta Was this translation helpful? Give feedback.
-
|
Having made extensive use of GOODF to modify the GUI aspect of my ODF, I now find I get no sound. The Organ looks right, but there is |
Beta Was this translation helpful? Give feedback.
-
|
After much rooting through the files I discover that GOODF seems to have discarded the [STOP..] and [COUPLER...] entries. |
Beta Was this translation helpful? Give feedback.
-
|
@William-Purvis I'll need much more details about what exactly happened and a way to reproduce the issue as such a thing has never happened for me! Please try to repeat the steps causing the issue and then open an issue at https://github.com/larspalo/GOODF where you describe it in detail. |
Beta Was this translation helpful? Give feedback.
-
|
I've only seen something similar when I moved the ODF to a new location before opening with GOODF. In that case GOODF can't find the pipe samples, so all the original samples get replaced with DUMMY. That didn't seem to have any effect on couplers though. |
Beta Was this translation helpful? Give feedback.
-
|
I've found the cause of the issue reported by @William-Purvis. It's simply because the number of the stop (and coupler) value in the odf is not zero padded (it reads instead like Stop001=1). I'll fix this soon enough. |
Beta Was this translation helpful? Give feedback.
-
|
I've encountered a warning message, browsing the user guide:
Followed the 'Using Windchestgroups' link and got:
HTML Anchor 6.UsingWindchestgroups|outline does not exist.
Probably not serious, and maybe already fixed.
Bill
…--
+----------------------------------------+
| Bill Purvis |
| email: ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
|
windchest.zip |
Beta Was this translation helpful? Give feedback.
-
|
I've updated all the help files recently. |
Beta Was this translation helpful? Give feedback.
-
|
The MouseRectWidth and MouseRectHeight don't appear in the .organ file when saved. GO seems to default to a square, but my stops |
Beta Was this translation helpful? Give feedback.
-
|
You might have to set MouseRadius to 0. Otherwise it will be the limit for the rectangle. |
Beta Was this translation helpful? Give feedback.
-
|
On 01/05/2023 13:47, larspalo wrote:
You might have to set MouseRadius to 0. Otherwise it will be the limit
for the rectangle.
—
Reply to this email directly, view it on GitHub
<#1394 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH27WM7UXEY2B3GV5XHVDYDXD6WGFANCNFSM6AAAAAAVALBVQI>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
But the ODF doesn't have any of the MouseReect.. or MouseRadius entries,
even though they show up in GOODF.
Unless you've updated GOODF since I compiled it (0.4.3)
I've edited them in (using emacs) and they now work as required.
Bill
…--
+----------------------------------------+
| Bill Purvis |
| ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
|
If the values of any of the mouse rect properties match the default values that GO will use then no such values will be written as they are not needed. GOODF will show the default values when you create/visit the element, but that doesn't mean they will be written (if they still would match the default values, that is). However, if you set the MouseRadius to 0 in GOODF it should write out that key/value pair and that alone should be enough. |
Beta Was this translation helpful? Give feedback.
-
|
When I edited the ODF with GOODF, it displayed all the Mouse... fields as I would expect, but none get written out. Under those circumstances GO simply treats it as a square equal to the width. I put the MouseRectWidth and MouseRectHeight in explicitly and still get the square area. Adding MouseRadius=0 (which was set in GOODF, but not in the saved ODF) finally gets it to respond to the full area. Maybe MouseRadius should always be written? |
Beta Was this translation helpful? Give feedback.
-
|
Just tested setting mouseradius to 0 and it does get written with latest GOODF (0.5.0), can't say for sure with 0.4.3. The strategy I've adopted for GOODF is to try to never write anything that GO will detect by default. Thus if a value matches what GO will use by default it doesn't get written. Many before have had trouble with understanding the relationship between all the mouse rect attributes and the mouse radius. The GO help has a slight typo regarding the max values for the MouseRadius, but in the end the all important sentences reads:
|
Beta Was this translation helpful? Give feedback.
-
|
OK, just ran a git pull and rebuilding. |
Beta Was this translation helpful? Give feedback.
-
|
Remember to tab out of the box if you just enter 0 as a value, otherwise it won't get stored! |
Beta Was this translation helpful? Give feedback.
-
|
Lars,
I've been getting into a mess trying to configure pistons. I don't
understand the difference between Piston
and ReversiblePiston. Also I think I need to define Couplers and
Divisional but neither seem to appear in
the GOODF sidebar. Can you refer me to something that explains these to
a non-organist. I have managed to
create pistons defined as Generals, but have been advised that that is
not what I need.
Bill
…--
+----------------------------------------+
| Bill Purvis |
| email: ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, long post coming... Reversible pistons are just an ancient way of manipulating other elements (in GO it can be any single item of a Stop, Coupler, Switch or Tremulant) from the button (or other mechanism). They just activate/de-activate the referred to item. They are seldom used in any organ nowadays as there are other ways to achieve the same means. One of the reasons for their existence is that it can be easier for the organist to quickly reach under the keys with the thumb and press a button than to reach out with the arm to activate a drawstop somewhere on a jamb. A piston in the general sense is a button that can be momentary (you push it and it springs back) or latching. Sometimes they are momentary with light to show the state. In GO, a piston is displayed smaller (and with other bitmaps) than a drawstop. Divisionals and generals are by default displayed as pistons (whereas drawstop types are not, but can be forced to). In GOODF the stops, couplers and divisionals are defined under each manual that they belong to. You create a manual and on its panel you have three buttons for creating a stop, coupler or divisional belonging to that manual. However. I strongly feel that the next information should be more generally known and adopted (both by users, sample set producers and hackers...). The old style of divisionals (belonging under each manual in GOODF) and generals (in the organ tree of GOODF) should really only be used if special reasons for it exist. It's much easier and less error prone to use the built in divisionals and generals that GO provide, and they are also very much more capable than the old style divisionals and generals. Main reason nowadays to use the old style of divisionals or generals for a GO organ is to model fixed type of combinations or to achieve certain tricks. For "general" usage (pun...) the built in versions of GO should always be preferred. So how to use the newer built in divisionals and generals? They are GUI elements of the setter type so you just define them on the panel you wish to display them on. (In fact, they are the same items available directly in GO under the Panel menu, but they can conveniently be referred to in the odf) The generals are very easy, you have the setter type named "GeneralXX" where XX can be 01 to 50. Then if needed you can switch banks for the generals so that you can in total have 999 combination slots. The divisionals are named "SetterXXXDivisionalYYY" where XXX is the manual number and YYY the divisional number. The only "strange" thing is the YYY with value 000 is actually divisional number 1 and YYY with value 001 is actually divisional number 2 and so on. The built in divisionals can also be banked in groups of 10, up to a total of 999 combination slots per manual. To get the built in divisionals to work correctly you should remember to add all the relevant items under the manual (tremulants, switches) and also preferrably enable the options on the [Organ] to store the items in the divisionals and combinations. That said, GOODF does make it less problematic to correctly define the old style of divisionals and generals that can be defined as presets with populated values ready to use. All of the content in this long post would have been much easier to show than to describe! |
Beta Was this translation helpful? Give feedback.
-
|
I'm developing my organ on my laptop and for various historic reasons the bulk of my organ code, samples etc. are stored on a |
Beta Was this translation helpful? Give feedback.
-
GOODF does check for real file existence and keeps track of both the absolute path to the files and also creates the relative paths needed for the odf as needed from where the .organ file is placed, it's not just a dumb text editor. Therefore one should always work on the .organ file in the exact relative position to where the samples are as you intend to use it. It's not possible to change the relationships between .organ file and the files used in it without problems. Though, if you have an identical sample set setup that you work on on one computer, it's of course possible to later move the .organ file to another computer without problems - but they do need to have exactly the same layout. Why the paths are changed in your specific case I cannot say as I know too little about the specifics. But if the paths in the .organ file works in GO just as they are (where they are), then GOODF should not really change them if you also edit the .organ file in exactly the same place where you later open it in GO. Bugs might exist though... |
Beta Was this translation helpful? Give feedback.
-
|
Hi Lars,
On 03/05/2023 19:41, you wrote:
Why can't it simply use the original path name?
GOODF does check for real file existence and keeps track of both the
absolute path to the files and also creates the relative paths needed
for the odf as needed from where the .organ file is placed, it's not
just a dumb text editor. Therefore one should always work on the
.organ file in the exact relative position to where the samples are as
you intend to use it. It's not possible to change the relationships
between .organ file and the files used in it without problems. Though,
if you have an identical sample set setup that you work on on one
computer, it's of course possible to later move the .organ file to
another computer without problems - but they do need to have exactly
the same layout.
Why the paths are changed in your specific case I cannot say as I know
too little about the specifics. But if the paths in the .organ file
works in GO just as they are (where they are), then GOODF should not
really change them if you also edit the .organ file in exactly the
same place where you later open it in GO. Bugs might exist though...
—
Reply to this email directly, view it on GitHub
<#1394 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH27WMZ2AMLW3X626BDGS2LXEKRHBANCNFSM6AAAAAAVALBVQI>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
I think you are maybe being too clever with it. All the GrandOrgue files
are on the same partition, with the samples
as a sub-directory of the directory containing the .organ file. I even
invoked GrandOrgue while in that directory
so pwd() will have the same path. If the file exists using just the
specified path, then there should be no need
to use anything more complex.
Bill
…--
+----------------------------------------+
| Bill Purvis |
| ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
Then I really cannot understand why the paths are changed! GOODF just use wxFileName to check for file existence and create absolute/relative paths from the odf root folder (which of course must be correctly set first!). Does this re-writing of the paths happen all the time for you or are there some specific conditions that trigger it? I'm curious if there's a bug lurking here or not! |
Beta Was this translation helpful? Give feedback.
-
|
As far as I am aware, the only time GOODF writes a path name is for Pipe entries, and it always does it for me. |
Beta Was this translation helpful? Give feedback.
-
|
Paths are written for any referenced file. The question is if the paths are re-written strangely in a saved odf for you all the time no matter what computer you work on or if there are special conditions that trigger it on your laptop and exactly what is being done to trigger it? Understand that this is not something I've experienced myself so I need to understand the situation where it might happen, in orter to possibly be able to prevent it. |
Beta Was this translation helpful? Give feedback.
-
|
On 04/05/2023 09:48, larspalo wrote:
Paths are written for any referenced file. The question is if the
paths are re-written strangely in a saved odf for you all the time no
matter what computer you work on or if there are special conditions
that trigger it on your laptop and exactly what is being done to
trigger it? Understand that this is not something I've experienced
myself so I need to understand the situation where it might happen, in
orter to possibly be able to prevent it.
—
Reply to this email directly, view it on GitHub
<#1394 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH27WMYLG7EQ253EJSVG5T3XENUNRANCNFSM6AAAAAAVALBVQI>.
You are receiving this because you were mentioned.Message ID:
***@***.***>
I guess that this is probably due to the fact that the organ files are
in a separate partition from my normal
user files. However, all the files relating to this organ, indeed all my
organs, is within a single partition.
If you are on Windows, then this is probably a very unlikely scenario.
It is probably not a common setup for
Linux either, but was expedient as my home partition was approaching
capacity, and I decided to put all my
organ-related files into a separate partition linked into my home file
system using symbolic links.
Bill
…--
+----------------------------------------+
| Bill Purvis |
| ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
I'd guess that the symbolic linking is causing the path problem for you. Can't you work directly on/against the files instead? GOODF really shouldn't have any problem working on files on an external hard drive or even an usb stick. |
Beta Was this translation helpful? Give feedback.
-
|
If you are on Windows, then this is probably a very unlikely scenario.
It is probably not a common setup for
Linux either, but was expedient as my home partition was approaching
capacity, and I decided to put all my
organ-related files into a separate partition linked into my home file
system using symbolic links.
I'd guess that the symbolic linking is causing the path problem for
you. Can't you work directly on/against the files instead? GOODF
really shouldn't have any problem working on files on an external hard
drive or even an usb stick.
Just ran a couple of tests. Wrote my organ folder onto a memory stick
(all 16GB) and ran GOODF on the .organ file.
Wrote back identically. Also ran GOODF on a copy of my current .organ
file, but selected it starting from the
top level of the partition. That wrote it back in the portable manner,
but it's an awful bind selecting it, quite
unnatural and quite a few extra clicks, working up to the top level,
then down to the current level. The symlink
is much more convenient.
…--
+----------------------------------------+
| Bill Purvis |
| ***@***.*** |
+----------------------------------------+
|
Beta Was this translation helpful? Give feedback.
-
|
Ok, so then it's more than likely that it's the symlinks that are causing issues for wxFileName to handle the paths. I've no idea if a more recent wxWidgets version would handle it better... Eventually we'll know, but for now I think I'm not going to worry about it. Sorry, but there are too many other things in life to do right now! Thanks anyway for testing GOODF, and please report any other issues you might find at https://github.com/larspalo/GOODF/issues. |
Beta Was this translation helpful? Give feedback.
-
|
I have created .organ files with this software where the .organ file is in the correct location with respect to the samples all under the symbolic link. I get the proper relative paths to samples, but I note that in the very first entry in the [ORGAN] window of GOODF, I have specified the "location of the .organ file" using the symbolic link for example |
Beta Was this translation helpful? Give feedback.
-
|
@davidgritter That is my experience too, GrandOrgue/GoOdf#19 (comment). |
Beta Was this translation helpful? Give feedback.
-
During the last year I've worked on a program to help creation (and in the future editing) of .organ files for sample set designers in a GUI application (=no text editing of code is needed). It's now performing good enough that I feel I can announce it's existance to the wider GrandOrgue community. For the moment you can find the sources and releases at https://github.com/larspalo/GOODF until further notice.
I don't doubt that there still are multiple bugs in, and issues with, the software - but more widespread usage will also help to reveal them. Also, I'm painfully aware that the software still is incomplete in many ways. Hopefully it can be further improved until it might actually take a rightful place as an official tool under the GrandOrgue organization.
If you're inclined to test it, I'm thankful for that and ask that you please submit issues or improvement suggestions at https://github.com/larspalo/GOODF.
Beta Was this translation helpful? Give feedback.
All reactions