Object List Overview

#1

Hello everybody,

I thought I needed an overview of all available Axoloti objects and their specifications in one document. So I made a little Java programm that parses all axo files in the objects folder of the Axoloti Patcher installation and generates a HTML page with all found objects and their specs.

You can find the object list file here:
http://www.privatepublic.de/public/axoloti-objectlist.html

(Caution: The above link is for the old 1.0.6 Axoloti patcher version! The links to the most current object list are in this post!).

This is a first shot and your feedback is welcome. I haven't had the time for now but I will publish the programm on github soon, so everyone can contribute or bug-fix :slight_smile:

Peter

An 'object' lesson for a new user
#2

cool,
logic/and 2 is still missing

#3

Very nice! Thanks for sharing

#4

No it's there. There are so many objects and sometimes I get lost finding them, too.
But keep on looking, please. There may be still some missing or falsely interpreted.

#5

I updated the styling a little bit to make the inlets/outlets better visible and readable. Maybe you need to explicitly reload the page in your browser to get the new styles.

#6

Ah, now i see there are two separate sections named "logic", why?

#7

Hats off, works great on iOS (iPhone/iPad).
Thinking/reading/Patching everywhere.

#8

@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.

#9

@timvets Now it's fixed. Thanks for watching. Don't forget to "reload" the page in your browser to see the changes.

Peter

#10

Brilliant!!!!
As a new user with a 2 hour commute everyday this allows me to think/plan patches on the train.

#11

Nice work on the object list @cpwitz :smile: Are you still updating it?

#12

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).

#13

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.

#14

Superb, thank you @cpwitz :smile:

#15

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

#16

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.

#17

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.

#18

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.

#19

Just thinking aloud, how about using travis-ci and "deploy" to a separate repo on github with only gh-pages?

#20

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)