sounds like u didnt delete start.bin on sd card....happend to me to...
Axoloti TEST release 1.0.8
@enic, found the cause
The preset recall buttons should only be enabled when a patch is live.
Thanks for the report.
That's good!
Do you also understand why I get "patch start taking too long, disconnecting", when the firmware is updated; is that normal?
It is normal, I'll change it in a more meaningful message.
Firmware flashing happens by loading a special "patch" (well it is not a patch, but uses the same loading mechanism), and then "jumps to the moon", it's currently not possible to sustain the connection while the firmware is flashing.
I encountered an issue with the File Manager running the patcher on Win 7 64bit. I'm not yet sure what it's capabilities are, so I may be off base here. Anyway, I inserted an SD card that I took out of my cell phone. It has a few pictures and some music on it, could be a couple of hundred files there, and it goes 3 folders deep. When I click Refresh, I get a "Ping: WaitSync Timeout, disconnecting now" in the console, the file list is not complete (the number of file varies between refreshes), and the Refresh button is greyed out. I have to restart the Axoloti Patcher to be able to do a Refresh again.
Edit: I also see folders for the patches I've taken live in the patcher - should they be on the SD card?
Sorry @DrJustice card should be formated BY Axoloti...
Think this is being implemented 1.0.8, so yes
probably not wise...
axoloti is optimised for real-time use, not doing large IO tasks like sending huge file lists to the PC.
its not really a bug timing out (though could be improved) , its just saying, this operation is taking longer that is normal.
I personally treat axoloti as a musical instrument, so give each its own card, and only put on it, the data needed for the patches I'm using etc.
I've read that it may affect performance, but not functionality(?) I want good performance of course, so I'll format with Axoloti then.
Right. I shall try to find out where that functionality is described.
I understand that it's a real time music device. I might want quite a few files on the SD card though, as in lots of patches, sequencer data and audio files. If there's a (practical?) low'ish limit on the number of files that can be handled by the File Manager that would be good to have in the docs eventually (or even better if this limit can be removed). I assume that there's no such limit other than for the File Manager itself.
Well, other than that I can report that going from 1.0.7 to 1.0.8 works fine for me. The main bug I hit in 1.0.7 is gone (object editor file saving)
ok, so @philoop has a number of times being able to get the following error:
Sync (pull) FAILED : community (master,philoop1)
org.eclipse.jgit.api.errors.NoHeadException: Pull on repository without HEAD currently not supported
can anyone else reproduce this, and whats steps are needed...
I need to know from a clean state i.e. where sync is working after an 'init'
what precise sequence of events lead up to this.
Ive been using this stuff for a while now, and Ive never had this.
Im assuming it has something to do with contributing ... but I cannot reproduce, and I contribute and sync regularly.
I suspect it might be something to do with NOT following the procedures Ive outlined, doing something in a different order than I have outlined, and shown in the video e.g. adding things into a directory and later adding contributor details but without someone detailing precisely the steps they are following I cannot solve it.
I'll reiterate :
If I don't have exact steps from a clean state to the error state, so that I can easily reproduce your error ... I cannot fix without this.
currently I have no issues with this library stuff - the effort to resolve these things must come from both sides, with users figuring out what leads up to these events, and then developers fixing the issue.
again, I urge you to watch the videos I made, are you doing something slightly different, if so what? if you stick to it, does it work?
Im simply not willing to spend hours randomly doing stuff, in the hope that I might accidentally work out what the user is doing. (this is not a commercial endeavour where we hirer a team of QA testers!)
EDIT : there were some 'fixes' in what will be 1.0.9, but Im not sure these will have any impact, these fixed an odd case with reinitialising, multiple times whilst axoloti was running, but the errors reported here, are not those that this had.
as mentioned on elsewhere, Ive got family visiting, so will not be able to put any significant time into axoloti for next few weeks.
For the "unidentified developer" issue, check this. It is for Lion, but it works for Yosemite so probably also works on your version of OSX.
http://www.imore.com/how-open-apps-unidentified-developer-os-x-mountain-lion
Hi,
Using version 1.0.8 on OSX 10.10.5 and when Syncing Libraries at the start, i got an error related to the annoying .DS_Store files that OSX creates.
I assume this is cause because i browsed the library folders with OSX finder.
After deleting the offending .DS_Store file all worked out correctly.
Shouldn't there be a .gitignore file for the contrib libs that makes it ignore the .DS_Store and similar files so that there are no conflicts when synching libraries?
It may create problems for less tech-inclined users in the future...
if this is in the wrong topic i apologize
there is already a .gitignore on the top level folder, with .DS_Store and also windows equivalent
see : https://github.com/axoloti/axoloti-contrib/blob/master/.gitignore
(was from my initial checking )
Sorry if this has been covered before, but..
How do I invoke the new Object Editor from within the Patcher?
a|x
edit definitions.
or edit on the patcher/object embedded object.
BTW: @johannes , we could do with a new version out, as the editor was broken in 1.0.8, but should be ok in dev.
Did you look into the "fallback to sd-card" idea you had, that we talked about? would that be implemented into new version if a new version surfaces soon?
Thanks.