@timvets It should reproduce the same structure as in Axoloti Patcher's object browser. And "logic" has a subfolder "decode". Therefore there a two lists: "logic" and "logic\decode". Or did I miss something?
.... Aaah, now I see. I will fix this with the next export! Thanks.
@timvets Now it's fixed. Thanks for watching. Don't forget to "reload" the page in your browser to see the changes.
Peter
Brilliant!!!!
As a new user with a 2 hour commute everyday this allows me to think/plan patches on the train.
Actually I am waiting until a new release is finished before adopting the object list generation to the new file structure. But yes, as soon as a new release is out I will update the list (give me some time for that, though).
Hey guys! I found a little bit of time to update the object list rendering. And here it is:
1.0.10 Factory Objects: http://www.privatepublic.de/public/factory-objectlist.html
1.0.10 Community Objects: http://www.privatepublic.de/public/community-objectlist.html
I improved the display style of the objects, that they almost look like in the patcher.
But be careful, there is one big caveat! The very vivid Community Library isn't updated automatically after somebody updated his or her objects. I try to update this list about once a week, but I'm going on vacation now and during this weeks, no updates will occur. It would be possible to automate this some time in the future with a git-watching server application, but at the moment I don't have a server infrastructure at hand to set something like this up. In the pages' headlines the date is printed when the list was rendered from the libraries. So you can see how current the data is, you're looking at.
Nevertheless, I am still planning to put the application on github, that is rendering this list from a local Axoloti installation. It's a quite simple Java application, but I want to prettify the code and make it a bit more robust before presenting it to the public.
Hope, you find it useful. And please, if you find any errors in the object representation, please post a report here. The dials don't display all variants (like unipolar/bipolar, gain or pitch/Hz) and the horizontal and vertical radio button parameters are only displayed somewhat shortened and not showing the real number of options.
P.S.: The old above mentioned 1.0.6 object list is also still available.
Last edit: Display components are now showing too.
Just uploaded further improved objectlists: The lists now also contain all subpatch objects (axs) and there's additional credit information (author, license) for each object.
And, if anyone is interested, the source code of the list generator is now on github:
https://github.com/privatepublic-de/axolist
This is great stuff, looks very cool...
@johannes / @cpwitz ... I wonder if we could get this automatically generated, and the results put onto axoloti.com? (with of course appropriate credits to @cpwitz for his great work)
my thoughts are that travis could build this... basically as a hook on the axoloti-contrib and axolotl-factory repos (similar to how automated builds are done).
I think the 'question' is how to then transfer the results to axoloti.com securely? this seems to be the 'hard' bit... but may be I'm wrong.
Id be a bit wary of having travis having credentials to axoloti.com, which is the 'easy/obvious way', but possibly insecure...
perhaps there could be some kind of 'pull script' being run on axoloti.com to pull the latest results from travis?
another way, might be to have the axoloti.com have restricted post options, so although travis does have the auth, its only to a very limited post request.
Thanks a lot! Actually if you guys are really interested in hosting the list and auto-update it, it would be easily possible to let the list generator automatically pull the libraries from github and if the axoloti.com hosting plan allows cron and java it could run, let's say, every hour and update the html files. Just thinking.
yeah, the reason i suggested travis, is it automatically runs a job whenever a check in is made, and gets a full image (again automatically)... so would mean automatic updating without any extra load on the axoloti.com server... except the propagating it to the web server.
(the only other thing it will need, is to know where to pick up the 'generator' jar from)
but I know @johannes is very busy at the moment, so this is more an idea for post-release.
Just thinking aloud, how about using travis-ci and "deploy" to a separate repo on github with only gh-pages?
its a good idea, but seems the deployment targets are quite limited in travis.
it mentions github releases, but not gh-pages.
but I found that its possible to encrypt data in the travis.yml file, see
https://docs.travis-ci.com/user/encryption-keys/
this means you could keep data required to update it to a server in the travis.yml without it being a security issue. e.g. username/password could both be encrypted. (ok, probably wise to use a 'special user' with limited permissions if possible, to be extra safe.
(also i guess it would be possible to change the java app, to post directly to the web server, rather than writing to a file, to reduce the number of steps)
I've never used travis - professionally we're jenkins-guys. But if travis can launch the jar and point it to the objects directories, it would be possible, that the java application then git-pushes it's render result to the gh-pages repository. Or it could render in a gh-pages repository-clone which then again could be pushed by travis. Since gh-pages are still a github repository, right? But i've no experience at all with travis.
What do you think?
ok, I took another look 
yes, we could publish to gh-pages for each of axolotl-factory and axoloti-contrib repos.
the trick is to use an RSA key pair, the private one is then encrypted using travis tools.
theres a good run down of how to do it for doxygen here, it doesn't matter what process you run.
http://blog.gockelhut.com/2014/09/automatic-documentation-publishing-with.html
(I think all I need to setup, is an axoloti gh-pages repo to be created, which I have contributor access to, so I can push the public key to it)
Hi,
I'm a bit hesitant to include this project into the axoloti source repositories itself, because it could complicate code maintenance. I appreciate the project, but in a way it is only re-presenting the information in objects from an independent codebase. I'd suggest to host it outside the output on another repo. I'm open to including a travis or jenkins job and key into the axoloti repos, that 'd be probably a script of a few dozen lines, to trigger the job on commits.
Don't get me wrong, I appreciate it, and 'd be happy to link to it, but need to focus my efforts.
Hey, I completely understand your hesitation. Because I don't know anything about axo's CI and deployment infrastructure I think I can't really provide much benefit to this discussion. If somebody found a lightweight integration solution I woud be happy to make the necessary adoptations/extensions to my java application. Just tell me what you need and you got it 
Java applications, web services and system integration are my daily business so don't hesitate to ask!
there are, of course, quite a few ways to do this....
if you want active triggers, then I think the scripts have to be in the travis.yml of the repo with the source thats changing (i.e. axoloti_factory/community), what these triggers do though of course is 'open'.
they could simply 'ping another web server' , which in response could do a pull.
otherwise you could poll the repos... not as nice, but can work.
in the last post, what I envisaged was just having a compiled jar from @cpwitz in the factory/community repos (in a tools directory), so its just replaced when/if there is a new version (e.g. if the xml format changes)
there is another side to this for the future...
I would interested to know how users are using this, such that the new object browser could do something similar within the app.
... but it maybe that users are enjoying this because they can see if without starting the app, in which case, the object browser can help this :))
I use it to get a visual overview of the whole object or group of objects whilst being able to see the inputs and outputs whereas the object viewer in the ui feels cramped with no resize options, it shows a single object and you have to click each object to see what type the outlets are.
This is useful for comparing and making decisions on selecting objects from a group that share the same name, it also serves as a good reference for existing patches without cluttering the UI (I run 2 screens, well, 3 if you count the 2nd PC).
hth.
Are you still updating it?