Invited contributions

#1

Hi developer,
(if you're not a developer, please do not reply to this topic)

I'd like to invite you to make some contributions to the development of Axoloti. I selected a few tasks have a fairly bounded scope, and limited impact on the source tree, unlikely to interfere with other ongoing efforts:

  • Adding some sort of automated checks to git commits, through travis-ci or something similar. So we immediately get a notification when something breaks by a commit to the axoloti-factory library, axoloti-community library and the axoloti repo itself. There are already a few command line options in the GUI to run tests, like "-runAllTests", but this has not been deployed systematically.

  • Adding an index.html file to every axoloti-contrib/objects/username/ folder with a link to the relevant community forum topic. This is pure manual work.

  • Integrating a markdown-to-html java library to enable markdown formatting in comments and object descriptions. The "pegdown" library seems a suitable candidate.

  • Inital configuration of Doxygen for the firmware code, integration in the compile scripts, perhaps also auto-deploying the output to a github page or something.

  • More gpio-PWM-like objects, exposing more possibilities of the STM32F4' timers.
    Pitch-tuned pwm generation, and precision timed one-shot pulses are the most common use cases I think.
    This could lead to some hybrid analog-digital synthesis circuits with a few external components.

  • Firmware: integrating generic HID support to USB host, for off-the-shelf usb gamepads, joysticks and other gadgets. This is quite a bit more involved than the other things here, and this is only extra "candy" functionality.

If you feel like taking on any of these tasks, or have something else in mind you want to contribute to, please give a shout (reply here, or PM), so redundant efforts can be avoided.

Thank you!

#2

I would be happy to participate to documentation :slight_smile: By documentation I hope to increase my knowledge about DSP!

#3

I would also be happy to participate in some documentation, I'm going to need to learn a little more about patching etc. first though I think.

#4

Participation in documentation is certainly welcome! For firmware, GUI code, tutorial patches and help patches, improvements can be submitted via github pull requests. For firmware documentation, the 1st step is creating a Doxygen setup. Multiple small commits are strongly preferred over massive changes.
Some documentation topics on the forum are really wiki posts, those can be edited. The forum does not handle simultaneous edits by different users I believe, but unlikely to be a real problem.
Thanks!

#5

Yes, sure!
What firmware part firstable do you need to include in docs? Driver? Filters? Math?

#6

First doxygen sample draft for a file (codec.h)

Pasted image637x667 33.4 KB

#7

Most important are functions that are relevant for coding objects.
Another thing is, there is a firmware branch in development ("spilink") which will need to be merged later, hope this won't cause big merging probs.

#8

Oh, yes...i see "spi-link" branch repo on github. So that will be the "next gen" firmware for axoloti?

#9

"spi-link" contains experimental code to exchange digital audio between two (or more) Axoloti Core's, and Control. It is still missing proper error reporting on the link setup, needs setup documentation, and more testing.

#10

We'll have double or n-axoloti core dsp power! Incredible! Shame on me, i've to buy 2 boards to test/debug this fantastic feature... :frowning:

#11

Well, i'm trying to merge the raw html documents by doxygen generated documentation; this is "one of the" attempts. Is this acceptable? or am I doing something wrong?

Pasted image936x648 46.8 KB

#12

I would better organize left menu and navigation experience, but i'm learning by working with doxygen :wink:, so, sorry for my slowness

#13

Hi all,
I've pull a request for documentation 2 day ago...any news about?

#14

Thanks, just sent my comments on the git pull request.

#15

@johannes
About your github comment, i've:
1) automated documentation building process by adding doxygen to dependencies and modifying ant script;
2) renamed files extension;
3) to better structurize browsing experience, I added some doxygen tags to html pages. Now, if you do not want this feature, you will get only plain pages without navigation anchors or tree; just a linked index.

#16

Sounds good, where do I find the pull request?

#17

@johannes
Sorry, but i can't...my github client show me the old pull request. No way to do new request.
May my last commit be in the queue of old pull request?

#18

if the old pull request was not 'closed' (either by merge/rejection) then commits will indeed be added to the existing pull request.

(FYI: only one PR is allowed per branch, so if you want new PRs then it has to be on new branches... not really applicable in this case, where you have just 'refined' the changes to meet requirements)

EDIT:
@paco the ant script appears to be only for windows... I think it should be for all platforms.
(its failing silently if not present, so appears ok for those without doxygen installed)

#19

Sorry @thetechnobear,
i haven't other OS to test. I don't know how to modify build.sh for osx and linux.

#20

Thanks for the update!
One way around cross-platform build testing is checking the build logs for pull requests on travis-ci. The latency is substantial though.
@thetechnobear do you suggest to merge the PR as-is, or create a separate branch to merge it into, and merge that into master when complete?