One of the, uhm, "improvements" Apple introduced with OSX 10.9 and later was that they changed how long OSX waits to self-assign an IP address to its Ethernet port. The new, longer value, can sometimes make it seem that KymaConnect cannot locate the Paca(rana). Normally this is hidden from you if you let KymaConnect run in the background and are not looking at its status. But if you are manually starting KymaConnect it might appear that something is broken if you do not give OSX enough time to obtain its IP address. This can lead to troubleshooting a non-existing problem.
TLDR - we have a write up about this problem here, and a recommended way to avoid it:http://www.delora.com/tips_and_trends/pacarana_networking/pacarana_networking.html. Since OSX 10.9 the delay has become so long that its best to just follow the advice in this article. Some further explanation follows.
Also, this Q&A addresses a similar issue that can cause the same symptoms. In this case the cause of the problem is a bug in OSX's Bonjour subsystem that was introduced in OSX 10.10 (Yosemite).
Normally IP addresses are either assigned automatically through the networks DHCP service (usually in your Wi-Fi access point or router), or they are "static", meaning they are manually entered and never change. Out-of-the-box OSX relies on DHCP. When it is configured to use DHCP, and it does not find a DHCP service, it then "self assigns" an IP address. This is actually the desired result in a typical KymaConnect set up where the Paca(rana)'s Ethernet port is directly connected to the Mac's Ethernet port (no router involved).
Prior to OSX 10.9, OSX's "I give up" time was under 10 seconds, and usually around 5 seconds. Since 10.9 this has greatly increase so that a minute or longer is not unusual. OSX will re-attempt to find a DHCP service every time it detects a change in the Ethernet connection, whether that is because it is unplugged at either end, or the Paca(rana) is powered on. So if your set up is like many where you power off the Pacarana after using Kyma, and the power it back on when you are about to start Kyma, you will run into this delay. However the only way you would ever notice this is if you were monitoring KymaConnect's status. Usually the time it takes the Paca(rana) to power up, plus the time it takes Kyma to launch and you load a sound, is greater than even the long OSX IP assignment time. So from a practical standpoints its not a problem. But if you are checking KymaConnect's status you may give up and start troubleshooting before OSX has self assigned.
The Paca(rana) also must be assigned an IP address every time it powers on, and it too searches for a DHCP service, but it has a much more reasonable time-out period so it self-assigns its IP addres fast enough to not be an issue.
The solution, which he discuss in more detail in the above link, is to manually assign an IP address (in the correct IP subnet) on the Mac's Ethernet port. Technically this is a no-no (again discussed in the article) but in practice it works fine.
KymaConnect is actually pretty robust and "self healing" so if it appears to wonky the best course is to just contact us (Delora Software) at our support email address, support[AT SYMBOL]delora.com.