Why won't my patch(es) go live?

Hm, I’ve tried going live using both library patches, as well as my own. I’m getting a string of errors in the log which, quite honestly, I’m not sure of their meaning. If anyone has any insight I’d be very happy to hear their thoughts! On a 2019 15" MBP running Catalina 10.15.6. Attaching an image of the errors here too.

I was having a similar problem and a reinstall helped me. Now I’m getting a different error:

USB device found
Connected to device.
Firmware version on attached device: 3.0.1.0, crc=0x9922E990
Control transfer failed: -9
receive error: LIBUSB_ERROR_PIPE
Disconnected from device.

I’m about to reinstall and see if that helps again!

Edit:

Nope. Same thing. Alternating my above error with:

USB device found
Connected to device.
Firmware version on attached device: 3.0.1.0, crc=0x9922E990
receive error: LIBUSB_ERROR_PIPE
java.io.IOException: java.util.concurrent.TimeoutException
java.io.IOException: java.util.concurrent.TimeoutException
at axoloti.connection.USBBulkConnection_v2.read(USBBulkConnection_v2.java:856)
at axoloti.target.TargetModel.readPatchName(TargetModel.java:391)
at axoloti.target.TargetModel.setPatchIndex(TargetModel.java:322)
at axoloti.connection.USBBulkConnection_v2.lambda$acknowledge_v2$2(USBBulkConnection_v2.java:1058)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
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.util.concurrent.TimeoutException
at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
at axoloti.connection.USBBulkConnection_v2.read(USBBulkConnection_v2.java:852)
… 16 more

disconnecting, reason: Device disconnected
Disconnected from device.

Gonna put this on the Git. Everything was working fine before. Don’t know what changed.

1 Like

Strange! I’ll follow this thread for potential updates.

1 Like

Most of the time, Nic looks at these things and is like, “Oh, geez, OK, try it now.” And that’s it. But he literally doesn’t have an apartment right now so he just needs support.

@JoshuaACNewman I now have an apartment at least. Boards arrived as well. Can you ping me in the evening at some point or this weekend? I’ll help you resolve this.

You bet! Congratulations on the apartment!

Try installing Xcode Toolkit.

In Terminal: " xcode-select --install "

If that doesn’t work, force it to reset: " sudo xcode-select --reset "

Is updated XCode already to see if that worked but I didn’t know you couldn’t “reset”it. I wonder what it’s doing!

It resets to the default command line tools path: /Library/Developer/CommandLineTools

alternative: " sudo xcode-select --switch /Library/Developer/CommandLineTools "

If none of the above methods work, login here: https://developer.apple.com/download/more/ with your Apple ID and look for “Command Line Tools for Xcode 12” in the list of downloads.

*Sorry for my poor english :slight_smile:

1 Like

Has Xcode always been required to run Axoloti on Mac?

Nope. But I was suspecting it because it meddles in Java.

I think It’ll be great when we’re not tied to Java anymore.

In the OP of this thread, it’s clear that xcrun is being used. This seems wrong to me.

Any evolution in this particular matter ?
I have erratic behaviours too when going live.
As an example, noticed that calling a table inside a polyphonic subpatch isn’t working…
(the ‘grainy-table’ patch in Library, for instance)

I think there are a few different potential issues here. @Nicotep Can you give me an example patch that fails? Relative to the now old Axoloti 1.0.12 release a lot of things have changed. There are definitely some issues related to subpatches. Log the issue on the Github issue patch with the example patch that produces the error. In general, if you find a confusing error in the output, don’t post it on the forum. Make a Github issue with a very specific name like “A patch with grainy-table inside of a polyphonic subpatch will not go live” and then attach the example patch.

The Xcode tools issue may be related to calling make, the standard unix utility, when compiling a patch to go live. If you’re seeing this error on MacOS, open a plain terminal and trying running the command make. If I recall correctly we include a make binary, but there could be something strange happening where that is not being resolved because of some Xcode path check. There should be no reason to require Xcode tools. We are accidentally triggering something there.

I think the issue is that it’s something other than XCode calling it, and it’s part of MacOS’ increasingly mall-cop-drunk-with-power security system.

I can run make from term (other than not giving it a file). I’ve been having issues with Axoloti, too, but I told the OS (in a secret way I can’t remember off the top of my head) to stop checking apps before opening. That’s right, I can’t say, “Nah, Axoloti’s cool, man. It can come in.” I have to fire the bouncer. If I hire a new bouncer, they’ll be so drunk with power I again won’t be able to run Axoloti.

Changing that security setting, though, didn’t fix Akso, and I’m speculating that there’s a special line for “if someone else calls make then call the cops.”

is there a progress on this topic. I run into the same issue and cannot compile my patch

I wish I could say yes. Nic came up for a gasp of air a week ago and I haven’t heard since. This time of year, nothing gets done. He’s been doing big work stuff, but man, I hope the issue we’re having is resolvable. I wanna build some shit!

1 Like

I am getting the exact same error message when trying to go live here. I installed the latest firmware (3.0.1.0) and apparently can connect to the card, Audio Midi setup sees it.

But the exact same error as the OP.

Macbook 15" 2016
Catalina
Akso is connected directly to the computer
LED is green.

2 Likes

The error message give you the problem in its first line: Missing xcrun.
A quick Google search leads to what seems like a helpful page here.
Another forum member (gus74) suggested exactly the same advice as is in that page earlier in this thread:
Did you try it? Did it work?

Holy crap. Inspired by the SD card question, I tried running with no SD card inserted and I’m good!

1 Like