Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Comments
It wasn't - I added it from my phone this morning
Just haven't gotten around to mentioning it yet, as I'm out of the office today.
Sounds good!
Regarding the rest: I don't really have any specific thoughts or plans here, I'm pretty much taking a backseat tech support role for now. But I think planning and coordination's a must, so fleshing out some structure's a good idea. I'll pop my head in when I can.
I created a page for wiki author tutorials and so far tags is all that’s on there. Any additional thoughts or advice on these subjects is welcome.
Someone's already created this too: https://wiki.audiob.us/author_tips
Added this to https://wiki.audiob.us/wiki_author page which I see as a work in progress although it’s becoming more clear that wikis are a continual work in progress which some older individuals such as myself have a hard time wrapping their head around 🤷♂️ .
It is a good idea to look at the site map before adding pages to see if a page already exists that touches on the subject you want to add.
I think it would be beneficial for there to be some discussion about pages where there is duplication or overlap.
I think we should also work out some structure and conventions before getting too deep. Reorganizing a wiki once it has a sizable number of pages tends to be messy as does reining in/keeping current a lot of duplication and overlap.
I'd like to set up a "sandbox" namespace (Dokuwiki's nomenclature for subdirectories) where we can put together trial versions of pages and drafts for discussion. Not sure when I'll have time for some real authoring.
Keep in mind now that if the wiki is successful there will hundreds or thousands of pages.
I've noticed that there are some pages that have been created that are manually created long lists of things like apps and some manually created pages for tags that start with different letters. In my opinion (and I have a fair amount of experience with these), such things become hard to keep up to date when dynamic tools can create such things.
It gets pretty cumbersome to manage such things -- and at this stage in creation, our time is probably better spent coming up with an agreeable overall structure, porting the existing (but scant) Knowledge Base topics and creating stub pages for key topics.
In my opinion, we don't need to create pages that list the tags that start with a certain letter or pages for the individual tags at this point. Much better to spend our time on gathering content -- even if articles start as pointers to relevant posts or external sites.
I am sorry if this comes across as overly opinionated. I've been around this block a few times and wish I had known about some of these things when I got my first wikis going.
Feel free to clean it up and start with a good foundation.
As a starter tree structure, I propose something like:
There is a value in their being some hierarchy (because one can easily generate page indexes for the branches of a tree. At the same time, too much hierarchy also gets to be hard to manage. Some wikis use no hierarchical structure and use tags for that.
I am curious what others think.
Got permission from a Facebook group to copy the AU3 list
https://wiki.audiob.us/audio_units
I'll work to add categories at least to the synths and effects. I find the hosts are a little harder and thus less useful for people to get clear consensus on definitions of.
Have you checked out the tag list page on the wiki? It’s basically a page for each letter where each line of the page is a link to a tag. It can basically be a mini dictionary. By adding the tag’s tag to its page, you can click on it and see where the tag is being used.
If enough people like the concept, it could be a quick way to look things up and see what sorts of information comes up.
At this point I’m just going to add tags I’ve actually used rather than trying to anticipate what tags might be used. Ideally only useful tags will end up being used in general so they have meaning for people who create content who will add or use tags which describe their content.
I’d be curious to hear what people think about the idea.
I’m kinda thinking for myself that I’ll start by creating “orphan” pages of interest to me, and not worry about where they go just yet. After all, structure can be added at any time by creating pages with nothing but links to other pages.
So, if someone comes up with a good starting index, it doesn’t mean I need to re-create anything about my page, or rename it. All that has to happen is to link to it on the appropriate page or pages. And, to better find it not going through a structure, to add tags.
I’m more of a “one-pile” kind of person. I almost never put saved email, documents, notes, etc. in any hierarchy. When I do, I have to think where I put it, and often get it wrong. I just use the appropriate search tool and my fast typing skills, and virtually always can find what I’m looking for. I know the very thought of that gives most people the heebie jeebies, but I also bet I find my stuff faster than most people eight out of ten times.
But I digress. Other than name-spaces (which I admit I don’t really understand), I can’t think of any reason to wait on “organization” to begin creating content. Once some structural documents start to emerge, I’ll happily link my stuff in them.
I did see that list of tag index pages. It's my opinion that we don't need those pages--or even a tags directory. Having such a proliferation of static pages won't be helpful in the long run. At this point I think a single tags page explaining how to tag pages is all we need--and we can add the dynamic tag table to that page when we have the infrastructure to generate it.
If people feel that we need a starter set of tags, we could have a list of "suggested" tags on that main 'tags' page.
By the way, the author tips page explains how to tag pages.
It will soon be easy to have dynamically generated tag lists/indexes. I am working with @Michael on getting some infrastructure set up to do that. When it is in place, I'll add info to the author tips page about how to set up dynamic lists of pages. So, we don't need static pages for that.
Generally, one doesn't need to have pages defining all the tags and their meanings.
I think at this point, the best use of people's time is grabbing valuable information from the forum and creating pages to house them -- and porting the Knowledge Base topics to the wiki.
Anyway that's my take. I probably won't be able to participate tons in page creation for a few days.
Namespaces are just nodes of the directory tree (i.e. subdirectories). The reason for having some sort of structure is so that the sitemap page makes sense AND it is often convenient to generate index pages dynamically by namespace.
The wiki has a dynamically generated sitemap. If there is zero structure and all pages are at the top level then it is hard for a visitor or author to get an overview of the site -- all they see is a list of 10 zillion pages -- remember: this wiki is likely to end up with hundreds or thousands of pages.
So, some basic structure is helpful.
If everyone just puts there pages at the top level, it will be hard to generate meaningful index pages (tables of contents for sections of the wiki). Too much structure has a downside, too.
Btw, noticed that "playground" (what I called sandbox) already exists. That is a good place to experiment.
When tagging pages, don’t go overboard with tags. Generally, pages will only need a few tags at most. Using too many tags on pages can make tag indexes less meaningful. For example, if AUM is mentioned on a page but the page is really about something else, it doesn’t need to be tagged with AUM.
Visitors can do searches using words, too. So, one doesn’t need to enter every word of possible interest as a tag only the most key ones. People mostly will search by word.
Think of tags as a targeting tool that prevents too many search results.
If you haven't done so already, this would be a good guideline to put on the author tips pages
Done. Also added info about YouTube embedding
This is a bit wacky:
Hey, a wacky wiki...
I've added a dynamic list of the tags in use to the wiki_author tags page paulinko created.
That probably isn't the ideal place to put it. Let's give some though to where such an index should appear.
I totally appreciate the effort and intention but am not sure that's the best approach to indexing/listing tags.
Does changing the namespace of a page change its URL?
Yup. Namespace is just the path it's in
Well ok then. The pages should ideally be in the right namespace to begin with to minimize broken links. Too bad.
If it were me, I wouldn’t use more than a few namespaces, and would simply use pages that serve as index pages. Index pages are so much easier to reorganize, re-format, etc. than a file hierarchy. I get that it makes the site map and auto table of contents creation easier, but I feel that tradeoff is not worth the sacrifice of flexibility. Argh.
I’m gonna be the outlier on this, I know. So I’m going to let it go. Y’all decide where to put stuff and I’ll suck it up and cooperate.
Ok, one last thought, then I will drop it: ask yourself, “How is WikiPedia organized?” It has a search engine and pages that link to other pages. That’s it. Works for me. That is all the structure I care to see. That’s what I always thought a wiki was supposed to be - a big pile of pages linked together organically.
I don’t get turning it into something else, but will drop it now and focus on writing some good pages.
It’s clear I’m out of step with many of what the other people doing the wiki want to do. At this point I’ll just create articles I want to make and post them where the collective will thinks they ought to go. My knowledge about wikis is small and limited so this isn’t too surprising.
I personally like to use a lot of tags as I like to see examples of different concepts illustrated with example pages. It seems others see this as clutter and confusion. I’ll go with whatever the group consensus ends up being.
The tag questions I was trying to address can be solved using the tag page much more effectively. It’s good the people with more experience and knowledge about how to create wikis are stepping up to help guide us (just to be clear if it isn’t already, this is not me). It will help us moving forward.
In retrospect it would have been ideal to have all of these issues worked out before the wiki was even created so people could know where and how to post their content contributions. The world of course can be a messy place with many conflicting priorities and a shortage of time to do them in. Focusing on how to move forward can quickly set things off in a positive direction.
I agree. I think I mistakenly extrapolated from the rate of participation of the Knowledge Base that things would move more slowly and that discussion about these topics would naturally precede a big jump in content creation.
It's all good. I think if people focus right now on creating articles of interest that a bit of re-organization at this early stage won't be too painful.
@wim wrote:
I read a great article some years back that talked about the ups/downs of various approaches to doing a wiki and also how the size of the community working on a wiki influences best practices and efficiencies.
A few quick things about that:
It is worth taking a look at a few wikis of different sizes and getting a sense of what people think work and what doesn't
Wikipedia is great, but it might not be the most apt model.
In any case, wikis are messy -- and require lots of back-and-forth as they develop. Hopefully we can avoid the ugliness that happens behind-the-scenes at wikipedia, too. (Another aspect of 'Darwininian' wikis that only move forward by natural evolution is that there can be acrimony that we probably want to avoid).
Anyway, that is my take. I am interested in what others have to say.
This is great, and mostly beyond me. Very refreshing after the murk of haters and climate Armageddon. Thank you, as always .
Do we need to have anyone denoted for anything in particular? Would it serve a purpose? Will it make @Michael's job easier? Like moderators, or even an editor(s)-in-chief? Someone(s) that will make the types of decisions not worth debating? Maybe someone with an overarching view or experience that we can cordially agree to yield to when discussion does not lead to definite action?
I think there is only one critical decision to make from the beginning. If namespaces are going to be used, then they are what needs to get put under control right away. Right now they are already a mess. Changing them is going to break every link. They need to be considered, cleaned up, and finalized right away. I’ve gone on record as saying I think they’re a really bad idea, but if we’re going to use them, they should be simple and static from the start.
I suggest that be the focus right now.
I’ll propose something very, very simple as a conversation starter:
That’s it. And no sub categories! Each namespace should have a home page that serves as a starting index, and the wiki home page should link to those. The namespace home pages are where people link the pages they have created (preferably in that namespace). These home pages can be expanded, organized, re-organized, table of content-ized, to everyone’s heart’s content - without breaking links.
The general rules should be:
That is the sum total of namespace organization I believe is wise. I’m not inclined to cooperate with an elaborate structure. If that happens, then all my postings will go in the root namespace and someone else can move them if they like (which will break links, but I won’t care).
Sorry for being so contrary and outspoken on this. But I believe I’m right, and I know from long experience I always regret it later when I don’t speak my mind and I turn out to be right.
Descriptions of proposed namespace content types
All this keeping in mind that namespaces are just file locations. There’s no reason a Tutorial couldn’t be linked from the Hosts page or any other page. But once linked, the page itself should stay in the namespace it is in. It isn’t going to be a big problem if something is in the wrong namespace. It will be a big problem if it’s moved since links will be broken.
My experience and perception of how things go on the forum is that when it comes to the nitty gritty details of actually creating some organized structure, there are relatively few people who will work on them relative to the number of people who post on the forum.
Keeping things simple, clear, and consistent while allowing people some autonomy to create their content would be ideal. If the process for putting content on the wiki is too burdensome, I predict few people will be participating in the process and those that do will have a bigger burden and become burned out.