When building from source on my mac, I found I needed to modify more build.xml files than I anticipated. I've listed some of them below. With enough such changes I can indeed build Jorgan and it makes noises and I can load some dispositions from elsewhere. So in that sense there is no "issue" at all.

However it also feels to me like there should be a few more options in build.properties which can feed down in a more natural way to the sub-packages so that other people in future building on mac don't have to solve the same problems I had to investigate.

I am hoping that perhaps by posing an issue here it might be possible to work toward such a resolution.

E.g. having set
mac.include = /Library/Java/JavaVirtualMachines/jdk-11.0.12.jdk/Contents/Home/include
in build.properties (which I did expect to change) I still had to add extra lines to jorgan-fluidsynth/build.xml as shown in the diff below.

--- a/jorgan-fluidsynth/build.xml
+++ b/jorgan-fluidsynth/build.xml
@@ -141,6 +141,8 @@
       <arg value="-dynamiclib" />
       <arg value="-std=c99" />
       <arg value="-I${mac.include}" />
+      <arg value="-I${mac.include}/darwin" /> <!-- LESTER -->
+      <arg value="-I/opt/local/include" /> <!-- LESTER : for fluidsynth -->
       <arg value="-I../jorgan-jni/src/main/native" />
       <arg value="-I./lib/include" />
       <arg value="-I./target/native" />

As you can see there are two extra lines above.

The FIRST additional line was because the header files installed in $JAVA_HOME/include by the https://download.oracle.com/otn-pub/java/jdk/11.0.12+8/f411702ca7704a54a79ead0c2e0942a3/jdk-11.0.12_osx-x64_bin.dmg installer oracle had me use contain files which are used by organ with names like:

${mac.include}/jni.h

which themselves contain lines like

#include "jni_md.h"

despite "jni_md.h" actually being one directory deeper in the darwin sub-folder. Presumably this is because jni_md.h contains system dependent code.

THIS FIRST ISSUE would be solved if build.properties contained some facility for me to include multiple include paths, not just a single one, for mac.include. Then I could include both my $JAVA_HOME/include and $JAVA_HOME/include/darwin. I did initially hope I might be able to do so by using some magic separator (like colons), e,g. setting:

mac.include=$JAVA_HOME/include:$JAVA_HOME/include/darwin

however the above (even if it were compatible with the java compile line, which I am not 100% sure it is) would still trigger a file-not-found failure in places in jorgan-fluidsynth/build.xml where tests like this are done:

    <fail message="mac.include not found - please check your build.properties">
      <condition>
        <not>
          <available file="${mac.include}" />
        </not>
      </condition>
    </fail>

I am neither a java nor an ant expert, so rather than attempt to fix the test above I just hard-coded extra include paths into the build line as shown in the original diff. However, it feels to me that someone who is a java/ant expert would be able to propose a better fix than the one I did from the get-go.

The second line you can see I added to jorgan-fluidsynth/build.xml was so that the jOrgan build could find my system's fluidsynth headers. Again, I just added the line so that the thing would compile, but I presume that someone more au-fait with ant would propose a more sensible high-level place to put such paths in a way that would be more maintainable for others in future?

In case anyone wants to see the sum total of all the changes I made, they can be seen in the "LESTER_M1_CONFIG" branch of my Jorgan fork here:
https://github.com/kesterlester/jorgan/tree/LESTER_M1_CONFIG

In my first attempts to build Jorgan on my mac I built against the jdk-16.0.2.jdk that Oracle presented me with as the default/current for my system.

Though building was successful, at run-time it became apparent that Jorgan was attempting to use some JDK interfaces which had been deprecated some years ago, and which had been in fact entirely removed prior to the release of jdk-16.0.2.jdk. Consequently Jorgan would crash on attempting to open (some) dispositions.

Having seen some hints on https://jorgan.info/base/m/Mac.html that (perhaps) only JDK version up to 11 were supported I went away and downloaded jdk-11.0.12.jdk . [This proved to be much harder than I thought it would be, as Oracle have made the task of getting hold of older version far harder than it needs to be on account of licensing issues ... but that's another story. ]

Building against JDK ver 11 succeeded (just as the build against JDK ver 16 had done) --- but with the added bonus this time that the program now ran properly as the deprecated interfaces Jorgan was using were/are not removed in this earlier JDK.

OK - so far so good.

My main thought, then, is would it be a good idea to remove the use of the deprecated interfaces so that users don't have to jump through hoops to find old versions of the JDK ? Of course, I could be wrong in assuming that the interface changes from JDK-11 to JDK-16 were the only things which one might need to fix to get support moved to JDK-16. I.e. perhaps there are other problems I didn't see.

But anyhow, in case it's useful, the main problem that I did see were all related to the MacAdapter "getInstance()" method in

./jorgan-gui/src/main/java/jorgan/swing/MacAdapter.java

being called by an OrganFrame:

./jorgan-gui/src/main/java/jorgan/gui/OrganFrame.java

Essentially, line 204 of MacAdapter's getInstance() method:

is supposed to do this:

adapter = new Real();

but instead throws an exception (which is caught) resulting in the adapter instead being set to a dummy adapter pin line 207 :

The cause of the throwing is that the Real() class being instantiated ( definition beginning at

https://stackoverflow.com/questions/9239287/what-is-the-alternative-for-deprecated-com-apple-eawt-applicationlistener/28090946

the handling of close/quit events is supposed to be handled not by Application Listeners but by calls to

com.apple.eawt.Application.setQuitHandler()      //, and
com.apple.eawt.Application.setQuitStrategy()

Someone who faced a need to fix a different program facing a need to transition from the old to the new interfaces wrote up their experience here:

https://discourse.processing.org/t/error-hello-processing-jdk-10-osx-high-sierra-com-apple-eawt-quithandler-not-supported/1396/3

However, unfortunately, despite staring at what's going on I don't feel able to see how to fix the issue myself.

Again, this may not be the ONLY fix needed to avoid being stuck on JDK 11 forever, but I am willing to help test potential improvements in this area.

jOrgan (version 3.21.1, build from SourceForge) crashes when trying to load a disposition on MacOS. It appears to run fine under Java 11.0.20.1, but under Java 17.0.7 it crashes. The error log is below.

Sep 25, 2023 1:45:17 PM jorgan.swing.MacAdapter unexpected
WARNING: unexpected failure
java.lang.NoClassDefFoundError: com/apple/eawt/ApplicationListener
	at jorgan.swing.MacAdapter.getInstance(MacAdapter.java:203)
	at jorgan.gui.OrganFrame.<init>(OrganFrame.java:142)
	at jorgan.gui.GUI$FrameInit.run(GUI.java:142)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.ClassNotFoundException: com.apple.eawt.ApplicationListener
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
	... 16 more

Sep 25, 2023 1:45:34 PM jorgan.gui.GUI$ExceptionInit uncaughtException
SEVERE: unexpected
java.lang.ExceptionInInitializerError
	at com.thoughtworks.xstream.XStream.setupConverters(XStream.java:990)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:593)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:515)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:484)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:430)
	at com.thoughtworks.xstream.XStream.<init>(XStream.java:397)
	at jorgan.io.DispositionStream$1.<init>(DispositionStream.java:69)
	at jorgan.io.DispositionStream.<init>(DispositionStream.java:69)
	at jorgan.session.OrganSession.<init>(OrganSession.java:79)
	at jorgan.gui.OrganFrame.openOrgan(OrganFrame.java:350)
	at jorgan.gui.OrganFrame$OpenAction.actionPerformed(OrganFrame.java:506)
	at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)
	at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2313)
	at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
	at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
	at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
	at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
	at java.desktop/java.awt.Component.processMouseEvent(Component.java:6626)
	at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3389)
	at java.desktop/java.awt.Component.processEvent(Component.java:6391)
	at java.desktop/java.awt.Container.processEvent(Container.java:2266)
	at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5001)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2324)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
	at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4948)
	at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4575)
	at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4516)
	at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2310)
	at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2780)
	at java.desktop/java.awt.Component.dispatchEvent(Component.java:4833)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:97)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:746)
	at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:744)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:743)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.Comparator java.util.TreeMap.comparator accessible: module java.base does not "opens java.util" to unnamed module @71bc1ae4
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
	at com.thoughtworks.xstream.core.util.Fields.locate(Fields.java:40)
	at com.thoughtworks.xstream.converters.collections.TreeMapConverter.<clinit>(TreeMapConverter.java:50)
	... 47 more

(This is more a question than an issue but I cannot find the "nabble" forum anymore. I highly suggest opening another one since mastering all capabilities of jOrgan is really tight)

Context

With jOrgan I'm using three series of switch filters, each series sending values for a different CC (for example CC20, CC21 and CC22).

Engaged: set 176, set 20, set XXX (first switch filter)
Engaged: set 176, set 21, set YYY (second switch filter)
Engaged: set 176, set 22, set ZZZ (third switch filter)

These switch filters are linked to ranks and I'm using modulators in a soundfont that listen to these CC values for changing the tuning.
My goal is to multiply XXX by YYY by ZZZ before changing the tuning of a soundfont preset and this could be achieved using linked modulators: a first modulator multiplies XXX by YYY and sends the result to another modulator that multiplies it by ZZZ and sends the new result to the fine tuning. The theory is OK.

Problem

But... linked modulators are not implemented yet in FluidSynth and thus only one multiplication is allowed. That's why I'd like to multiply XXX by YYY within jOrgan before sending the result to the soundfont.

After the reading of these pages:

• https://jorgan.info/base/Midi.html
• https://jorgan.info/base/c/Continuous_filter.html
• https://jorgan.info/base/s/Switch_filter.html

My first attempt was to intercept values of CC20 (XXX) and CC21 (YYY) in a switch or a continuous filter, before sending the result as a new CC (number 23).

Intercept: equal 176, equal 20, get valA
Intercept: equal 176, equal 21, get valB
Engaged: set 176, set 23, set valA | mult valB

This way, in a soundfont I would just need to multiply CC22 (ZZZ) by CC23 (containing the result of XXX * YYY).
But the CC values don't seem to be intercepted by the switch or continuous filter.

The other solution I thought but that is not allowed is to intercept messages in a rank.

Question

How would it be possible in jOrgan to intercept CC values, multiply them and then send the result to a specific MIDI CC?

Using paths with spaces in the *.include or *.cc variables will result in the path being used with unescaped spaces in the various commands and it will be treated as multiple paths (i.e. "C:/Program Files/jdk11/include" = "C:/Program", "Files/jdk11/include"). This results in commands failing (i.e. the jorgan-creative build fails with win.include not found - please check your build.properties).

This is particularly a pain if you try to target a system-installed JDK on Windows, since by default it installs in Program Files. I'm not that familiar with Ant, so I'm not really sure how to fix this issue; Using escaped quotes in either the commands that use these variables or the variables themselves does not work, neither does escaping the space, etc..

This stackoverflow seems suggest a fix for the issue, but I'm not sure how to apply it to the build files: https://stackoverflow.com/questions/10709314/ant-file-set-using-path-with-spaces-in-it

Context

I'm using a MIDI console, comprising a push button and a LED for each stop. If I trigger such a button, a signal is sent to jOrgan, then the corresponding stop is toggled and finally the state ON or OFF is sent back to the console that switches the LED ON or OFF. Another trigger on the same button toggles the LED.

Problem

When opening jOrgan, some LEDs are not correctly initialized. Maybe it comes from the electronic cards that don't catch everything but I'm using cards from two different builders and the same issue appears.

Maybe it's also a bug from jOrgan. But one way to overcome this issue would be to specify a series of MIDI signals to send to the console, AFTER the existing initialization. In my case, "all notes off" for 3 channels and a "ON" signal for a specific LED (bank 1):

set 176, set 123
set 177, set 123
set 178, set 123
equal 144, equal 78, equal 127

This is what I specified in my GC button (that also deactivates everything except the combination called "bank 1").

Request

It would be nice to specify somewhere the MIDI signals we want to send to the MIDI console AFTER the existing initialization, for example a kind of message to insert in a connector element. Alternatively or in addition, we could imagine an extra feature to buttons such as a combination or an activator, so that it activates itself automatically when the organ is loaded.

I'm not really certain how to build this; ./build.sh fails on Ubuntu 20.04 with JDK 11 and 15 with complaints of no jni.h. What are the build requirements?

I discovered on a Raspberry Pi a weird behavior.
To describe the issue I made a minimal disposition comprising:

• around 60 stops
• a combination "tutti", enabling all stops
• a combination "global cancel", disabling all stops

bug gc-tutti lag.zip

If I click on the combination "tutti" with the mouse, all stops are enabled instantly.
But when I link this combination to a MIDI signal that activates it, we are able to see that the stops are not enabled instantly. This is still fast, but with a heavier disposition this can impair the sound (stops are progressively enabled and the effect is not very nice when playing).

I tried to synchronize an activator to the combination, the activator being linked to a MIDI signal, but same problem.
This is like the signals or not processed the same way if we click or if we use a external MIDI signal.

After a Fedora update from version 35 to version 36, jOrgan is not able to open a disposition anymore.
I have two versions of the java JDK: version 11 and version 17. With version 11.0.15 everything is working correctly but with version 17.0.3 here is the error:

GRAVE: bootstrapping failed
java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at jorgan.bootstrap.Main.<init>(Main.java:31)
	at jorgan.bootstrap.Bootstrap.start(Bootstrap.java:39)
	at jorgan.bootstrap.Bootstrap.main(Bootstrap.java:48)
Caused by: java.lang.Error: java.lang.reflect.InvocationTargetException
	at jorgan.gui.GUI.invokeOnSwing(GUI.java:212)
	at jorgan.gui.GUI$FileInit.<init>(GUI.java:194)
	at jorgan.gui.GUI.display(GUI.java:79)
	at jorgan.App.start(App.java:66)
	at jorgan.App.main(App.java:100)
	... 7 more
Caused by: java.lang.reflect.InvocationTargetException
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1369)
	at java.desktop/java.awt.EventQueue.invokeAndWait(EventQueue.java:1344)
	at java.desktop/javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1480)
	at jorgan.gui.GUI.invokeOnSwing(GUI.java:207)
	... 11 more
Caused by: java.lang.Error: Unable to make void java.awt.EventDispatchThread.pumpEvents(java.awt.Conditional) accessible: module java.desktop does not "opens java.awt" to unnamed module @383534aa
	at spin.off.AWTReflectDispatcherFactory.<clinit>(AWTReflectDispatcherFactory.java:144)
	at spin.off.SpinOffEvaluator.<clinit>(SpinOffEvaluator.java:38)
	at spin.Spin.<clinit>(Spin.java:68)
	at jorgan.gui.OrganFrame.setSession(OrganFrame.java:305)
	at jorgan.gui.OrganFrame.openOrgan(OrganFrame.java:358)
	at jorgan.gui.GUI$FileInit.run(GUI.java:198)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Maybe this is a bug on the java JDK side.

It's mentioned here that launching a jar with an additional module would work but I probably didn't find the right module to add.