If you encounter an issue with Axoloti, please report your issues here.
Note: this is for hardware and software problems only i.e. bugs, patches that don't work as expected should be discussed in the patching category initially... unless its clear that an Axoloti Object (axo) is not working as designed.
Reporting bugs
When you report an issue please:
- Include as much info as possible about your setup,
- Computer: Mac / Linux /Windows - and which version of the operating system?
- Are you connecting via a USB Hub?
- Other hardware (What controller are you using? are you using Midi DIN or using USB hosting?
- Which version of Axoloti are you using? (displayed in the Help/About dialog, at the top)
Include information on how to replicate the issues/bug
This is important, a developer cannot possibly fix a bug if they are not able to reproduce it... and even if they could, then they would not be able to test the fix!
so write detailed steps on how to reproduce the problem, with as few steps as possible (see 'be concise')
Include logs, as much as possible for leading to to eventBe concise
Try to cutdown the possible causes as much as possible, simplify the problem. This helps developers focus on the cause of the issue. e.g. if a patch doesn't work because an axoloti object is behaving incorrectly don't report with a patch with 100 objects, try to create a patch with just a few objects with exhibits the same issue.
This step is tricky, and don't be drawn into making assumptions about the cause, it may not be what you think it is.Include example
If you have a patch that exhibits the issues, then please include it.
Support process:
Report the issue here, where it can be discussed with the community, perhaps its a configuration issue, or a something that is not currently implemented.
If it is determined that its a bug, or an agreement has been reached about adding it as a feature request, then you will be asked to raise it as a 'github issue' by using https://github.com/axoloti/axoloti/issues, doing this will create a unique issue number, which will allow you* and developers to track the issue. (we ask you to enter it, so you can track it, and also developers can ask more information from you if required)
Patience... Johannes is one-man aided by other community members, so they may be busy, on holiday... and may also be in a different timezone. Hopefully the community can help out for many things quickly, but sometimes a bit of patience may be required. If after a few days, you have not heard anything, then please 'bump' your post, in case some how its been missed.
Supporting builds from Github.
Obviously supporting 'released' versions is simpler than builds that are being made directly from github, of what is potentially unreleased software/changes. If you are doing this, then please before reporting, try to test against the release build, and also be very clear when reporting that you are building from github, and which branch you are using.
A parting thought...
Please remember bug reporting is all about communication.
Its like telling a story... just telling the developer the how it ends, really is pointless,they need to know what led up to the ending ( preferably a short story that focuses on the important points 
)
the different between a good bug report and bad is to a developer is huge:
- a bad bug report ("my app crashes") feels like the user can't be bothered to put in the effort to detail the issue... the developer created the issue, they have to fix it!
- a good bug report feels like the user wants to help the developer resolve the issues, and make the product better, a collaboration...
Guess which the developer feels more motivated to investigate?
(and of course the later, also has more information to start that investigation!)
getting good bug reports is difficult, and all projects generally ask for the same thing, so theres lots of tips on how to write good bug reports if you search the internet, heres one that seemed a good starting place.
http://noverse.com/blog/2012/06/how-to-write-a-good-bug-report/