Forum Replies Created
-
Posts
-
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.
Doug
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?
Some background…
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.
Is the Linnstrument connected to the Pacarana’s USB Port? If so then you should pass on your observations to Symbolic Sound. If it is connected to your Mac and assigned to one of KymaConnect’s External MIDI, then it should not show up in DSP status. That is reserved for showing the USB or FireWire MIDI device it is currently using.
The IAC Sends are really still from old times, where I did a little more complex MIDI pros.
Now I use much more OSC 🙂So I could do without the single IAC bus in “Ext. out ” if I just want to separate the reception of KymaConnect in Ableton Live according to MIDI channels.
Keep using the IAC’s with the EXT MIDI slots if that works for you. I was mainly curious to better understand your use-case.
IPv6 was actually set to “off”. I have now set it to “automatic” and repeated step 3. Only this time I also disabled my Ext. in and outs in KymaConnect.
It works KymaConnect is fully connected according to the status display:)Excellent news! Looks like there is no longer a reason to use the PacaDHCP work-around. You can re-enable your EXT Midi slots and just ignore the yellow status indicator. As long as the two LEDs near the Pacarana are green you have a working connect.
I can confirm that the bottom status LED is showing yellow due to a minor bug. It is incorrectly interpreting a Ext MIDI slot with either the input or output set to “not connected” as an error.
Out of curiosity, why are you creating an IAC port to receive MIDI from the Pacarana? Are you using KymaConnect’s routing and filtering to modify the MIDI stream?
