Forum Replies Created
BETA 6 is available from the Kyma Community Library: KymaConnect 2 BETA. This replaces BETA 5, which will be cease working on December 1, 2020. BETA 6 expires on February 1, 2021.
This is a significant release because it supports macOS 11 (Big Sur) and the executable is now a “Universal Binary” that will run natively on either Intel or Apple Silicon processors.
Aside from a minor improvement to the GUI on macOS 11, the operation of this release should be identical to the previous BETA 5. The only difference is the use of the latest Apple tool chain, and the inclusion of Apple Silicon support in the Universal Binary. Behavior on macOS 10.14 (Mojave) and macOS 10.15 (Catalina) should be the same as it was for the previous release. If you think you are seeing different behaviors, even small differences, please report them in the Kyma 7 Community Forum thread.
If KymaConnect is not seeing MIDI activity there is more than likely none. Best to verify though with MIDI Monitor.
Does the control have a power switch so you can turn it off and leave it plugged into USB? If so try switching it off before restarting you Mac, and switch it off before letting your Mac go into sleep mode. Give the Mac time to wake up, or start up, before switching it on.
As I mentioned I have experienced this type of USB MIDI issue a relatively recent model from a top brand. I have attributed the problem to the USB hub but it might do it even if I plugged it directly in the Mac. Turning its power switch off, then back on always brings MIDI back to life, and I never have the problem if I remember to switch it off before sleeping or shutting down the Mac.
Sounding more and more like a driver issue.
I do have the Akai and Akai Port 3 in two External inputs. Not sure what Akai Port 3 is, but figured I’d connect it and find out.
That is not what I meant by multiple entries. I was interested whether you see a complete duplicate set of ports for the Akai in the port list. Usually when CoreMIDI does that you also see duplication in AudioMIDI Setup, with the duplicates grayed out.
Not sure if this is new behavior with update or not. I just added an Akai MPK49 MIDI kbd controller, which is bus powered. After launching Kyma, KymaConnect doesn’t recognize MIDI transmission from it, although it does recognize that it is connected. After unplugging/replugging USB, MIDI transmission works just fine.
When you say that KymaConnect does not recognize MIDI transmission do you mean that you do not see MIDI activity in Kyma’s DSP status window, or that KymaConnect’s activity LEDs are not showing MIDI activity?
One thing to try is to have KymaConnect stopped when you first plug it in. See if there are two entries in the MIDI port list for the MPK49.
I have seen this identical behavior in other applications, like Logic, with other class-compliant, USB-powered controllers. The controller is recognized by the software but there is no MIDI reception until it is either turned off and then back on, or unplugged and re-plugged in. I suspect this is related to a problem in macOS/CoreMidi.
Also noticed that it only seems to work when connected to the right-hand side USB port on 2016 MBP, not the left-hand side port.
Try plugging it into the left-hand port with KymaConnect not running and then inspect the available ports KymaConnect shows. See if the MPK49 is showing. Record the full name that KymaConnect is showing, if it shows up. Repeat the same experiment with the right-hand port and look for a difference between the port names.
CoreMIDI considers the same device connected in two different USB paths to be different devices. Historically KymaConnect also treated them as different devices, which meant that changing USB ports would cause a configuration to no longer work. BETA 4 added code to help this situation but there are situations which it cannot handle. I discuss this in more detail in the BETA 4 release comments in this forum message: https://kyma.symbolicsound.com/forums/topic/kymaconnect-2-0-beta/#post-1897
The last paragraph may be what you are experiencing with your left/right USB ports.
BETA 5 is available from the Kyma Community Library: KymaConnect 2 BETA. All KymaConnect 2 BETA users must update immediately; Previous BETA versions, including BETA 4, no are no longer valid. Please discard previous BETA installers.
BETA 5 is available from the Kyma Community Library: KymaConnect 2 BETA. All KymaConnect 2 BETA users must update immediately; Previous BETA versions, including BETA 4, no are no longer valid.
The macOS 10.16 (Big Sur) release is rapidly nearing. We are testing KymaConnect 2 on macOS 10.16 but additional user testing is very helpful.
The interesting thing about the error message of the operating system was that it was like a virus warning where you could tell Apple right away that it was malware.
Now, if a KymaConnect user mistakenly declares the installer to be malicious during installation, does this perhaps have a negative effect on other KymaConnect installations of other users? I hope that this is not so bad.
I do too! I don’t believe that is the case but have no way of proving it without risking making matters worse.
TO ALL KYMACONNECT 2 BETA USERS
KymaConnect 2 BETA 4 no longer operates. You will see the kind of error message that Knut Kaulke noted in post 1921. Reinstalling using the BETA 4 installer will not resolve the problem and will show the misleading message noted in post 1922.
We have the new BETA 5 installer ready but cannot currently upload it to the Kyma Community Library. We are working to resolve this issue, and if necessary will provide an alternative interim way to download the installer. I will post a message here once I know more.
If you have a pressing need to use KymaConnect 2 please contact me using email at support (AT) delora (DOT) com. Together we can figure out how best to get you the installer.
Previous releases of KymaConnect 2 BETA (1, 2, 3, 4) are no longer useful. I recommend that you delete them to avoid possible confusion.
When I use the current Beta-installer for reinstallation, I get the error message at the end:
“kymaconnect_agent_stop” damages your computer.
This is a false warning. There is nothing in the BETA 4 installer that can damage your computer. macOS Catalina is showing this message because “kymaconnect_agent_stop” was codesigned by a no longer valid certificate. This is related to the same problem that caused KymaConnect 2 BETA 4 to stop working. “kymaconnect_agent_stop” is a utility program that has been part of the KymaConnect installer for a long time. It is used to stop the KymaConnect agent before performing the installation.
I have a problem with the current beta version under macOS 10.15.6. Suddenly after starting my computer I get an error message in the system settings that KymaConnect cannot be loaded. Yesterday everything was still running fine.
Could it be that my switch from bash to zsh login shell has something to do with this?
I am sorry that you ran into this. This was not caused by changing the login shell. There is a problem with the KymaConnect 2 BETA 4 that caused it to stop operating before the planned expiration date. Restarting the computer, logging out and back in, will cause the agent program to halt. If you try to access the KymaConnect preference pane System Preferences refuses to load it and you get the message you saw.
We already have KymaConnect 2 BETA 5 ready for distribution but are unable to upload it to the Community Library at the present time. We are working with Symbolic Sound to resolve this issue.
If anyone sees this message, and there is not any follow ups saying BETA 5 is available for download, please contact me directly via email = support (AT) delora (DOT) com and I will arrange with you to get you the BETA 5 installer directly.
I am very sorry that this has happened!
I work with the Lemur Daemon, whose ports I specified in KymaConnect. When starting my Mac I have to set these ports in KymaConnect every time. Is it possible to change this in version 2 of KymaConnect?
Is this for use with original JazzMutant Lemur hardware controller, or for the Lemur app?
The original JazzMutant Daemon, and its successor the Lemur Daemon, both do not create the eight CoreMIDI virtual ports (Daemon 1, Daemon 2…) in the manner that CoreMIDI expects. The Daemon utility creates a completely new set of virtual MIDI ports each time it is run, instead of recreating the same set from the last time it ran. It gives them the same name but CoreMIDI does not use names to differentiate ports; names are not guaranteed to be unique. This is why you have to reconnect things in KymaConnect, and most other applications (including many DAWs) each time you restart Lemur Daemon.
Is a work around even necessary?
Tablet Lemur users can completely avoid this problem by one of two methods:
1. Do not use Lemur Daemon but instead make all of your OSC and MIDI connections direct from the Lemur app. The app supports network MIDI so it is possible to create a network session on the Mac that is running KymaConnect and connect that session to the iPad’s network MIDI session. Each Mac network MIDI session creates its own virtual midi I/O port. That can be assigned to one of KymaConnect’s EXT MIDI slots. The main limitation of this method is that the iPad can only have a single network MIDI session active. So you cannot have a Lemur template sending different MIDI data to different MIDI destinations, or receiving differentiate the source of MIDI from multiple MIDI sources.
2. Continue to use Lemur Daemon but do not use the Daemon 0 – Daemon 7. Connect to vPacarana. The Lemur Daemon will remember the connection and restore it whenever vPacarana is available (i.e. when KymaConnect is running). Since you are directly connecting to the Pacarana through the vPacarana port there is no need to use one of KymaConnect’s EXT MIDI slots to communicate with the Lemur.
My testing with original Lemur hardware has shown that it is not compatible with the newer Lemur Daemon, and unfortunately, the original Jazz Daemon utility is a bit broken with how it handles CoreMIDI ports. It does not properly respond to changes in port availability. Method #2 may work with Jazz Daemon but you must launch Jazz Daemon after your MIDI ports are already available, otherwise the ports will never show up as available in the Daemon. So you have to make sure KymaConnect is running (but not necessarily connected to the Paca!) before you launch Jazz Daemon.
You once asked in Q&A about the Wormhole setup in Kyma7+. Are there any new findings in using KymaConnect?
I do not have access to multiple Pacas/Pacaranas to verify this myself so I can only relay what I have been told by others. The official Symbolic Sound information that I have comes from the Kyma 7.35f0 release notes (2020-07-01):
Wormhole now works with an Ethernet connection to the host computer (substituting for the FireWire connection from Paca(rana) to host computer): use four Cat6 gigabit Ethernet cables and a gigabit Ethernet switch (for example, a NETGEAR GS305):
- Host computer Ethernet to switch
- Paca(rana) #1 Port A to Paca(rana) #2 Port A
- Paca(rana) #1 Port B to switch
- Paca(rana) #2 Port B to switch
This confirms that you can set up a Wormhole that uses only the computer’s Ethernet connection to communicate with the Pacas (no FireWire to computer necessary). When the host computer is a Mac running KymaConnect, or even a Mac as a second computer connected to the same Ethernet switch, KymaConnect works as expected.
Wormhole set ups have always had a limitation that prevented KymaConnect 1 from operating correctly without a work around called “PacaDHCP” that I created and provided to interested Wormhole users. The limitation had to do with using IP4 for network connections. KymaConnect 1 can only operate with IP4.
KymaConnect 2 supports IPv6 and IPv4. If the network connection between the Mac running KymaConnect 2 and the Pacarana (or Wormhole) is configured to allow IPv6 connections then the PacaDHCP work around should not be necessary. Wormholes should “just work” with KymaConnect 2, provided the set up uses the Ethernet switch as outlined above.
IPv6 is enabled by default on macOS network ports, and it is unusual for IPv6 to be disabled. So I would not expect users to have to do any special network configuration related to IPv6 support.
As I mentioned above, I have no way of directly confirming that the Wormhole set up now works like this. I have, however had a BETA user report success.
The bug where KymaConnect was not displaying the correct device name should be fixed in the just release (2020-07-24) BETA 4. If the problem reoccurs please let me know.
BETA 4 is available from the Kyma Community Library: KymaConnect 2 BETA. There are a number of UI changes, including better reporting of MIDI devices that are no longer connected, powered off, or otherwise unavailable. Please read the release notes that you can find in the “KymaConnect 2” folder your Mac’s “Applications” folder for more details.
We are now actively testing on the macOS 10.16 (Big Sur) BETA. If anyone is testing their workflows on the macOS 10.16 public beta please give KymaConnect a good work out and report your findings.
A bit more details on the biggest change in this release: handling missing MIDI devices. Previously when a MIDI device assigned to one of the EXT MIDI slots was not available the slot assignment, and the MIDI device pop up, would display <Unavailable>. Sometimes though it would show a multi-digit number.
Now what you should see is the actual name of the MIDI device with “(unavailable)” added. Sometimes though it will show “<Port Unavailable> (a_number)”. Why not the name always?
CoreMIDI does not retain a history of device names. Each device has a unique identifier number which applications are supposed to use to remember device assignments. The number that you sometimes previously saw in the popup is the device’s unique identifier.
KymaConnect 2 now retains a short record of previously known device names paired with device unique identifiers. It uses this record to display the much more friendly name when the device is unavailable.
If you have assigned devices in the past that are not available when you run BETA 4 then you will see “<Port Unavailable> (a_number)” for that device until you connect it. After that you should see the actual name even if you disconnect or turn the device off.
The display name is also used on KymaConnect’s status screen while KymaConnect’s agent is running. Slots with ports that are unavailable show an amber/orange colored status LED. KymaConnect works OK when a device is missing but will show “yellow” for the overall run status.
One thing to be aware of is that some USB MIDI devices change their unique identifier when connected to a different USB hub, or even sometimes a different USB port. This is why AudioMidi Setup seems to collect multiple copies of a USB MIDI device, all but one copy displayed as “greyed out”. KymaConnect 2 depends on the unique identifier so as far as it is concerned these are different devices. Consequently if you have such a device and change how it connects to your Mac KymaConnect may still show the device as noty connected even if it is. Just select the device in the popup menu and KymaConnect will use the “new” device, and will forget the old copy.
Each BETA release has an expiration date. For example the most recent release, BETA 3 (build 200.3), is scheduled to expire on August 1, 2020. Should you be concerned that the KymaConnect 2 BETA will stop working then?
Each time we release a new BETA build we extend the expiration date, typically a month or more. Should it ever happen that we do not have a product improvement reason to release a new BETA version before the expiration we will release a new BETA just to extend the expiration date. This will continue until we are ready to conclude the BETA period.
So expect a new BETA version sometime before August 1, 2020. I will announce it here in the forum when it is available from the Community Library.