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.
Wiki Namespaces?
There has been some discussion about what sort of hierarchy, if any, the wiki would benefit from.
Here are some thoughts for consideration. I am curious what y'all think.
We aren't limited to just these possibilities. These are ideas that may provide helpful structure (making it easier to build non-overwhelming tables of contents) without becoming too complicated.
Option 1 - The Minimalist
- "main" (all pages not in wiki or playground would simply live at the top-level of the wiki
- wiki (created by dokuwiki at install) - pages with information relevant to authoring wiki pages
- playground (created by dokuwiki at install)
Option 2 - Less Minimalist
- iosmusic -- pages related to ios music-making. this would include articles about any ios software and related hardware
- knowledgebase -- pages related to anything else. For example, articles about Subtractive Synthesis, sample rates, granular synthesis would go here
- users -- user-created pages for information or music that they'd like to share
- wiki (created by dokuwiki at install) - pages with information relevant to authoring wiki pages
- playground (created by dokuwiki at install)
Comments
The main namespace issue is organization. If there are some big discrete categories of pages, it simplifies index and table of contents creation and can make it easier for visitors to find what they need.
If you visit good wikis around the web, you find a variety of approaches. There is no one-size-fits-all best approach.
Something like wikipedia requires a minimal approach because it is a collection of totally unrelated information that doesn't fit into a small number of discrete categories.
Some wikis house information that naturally lends itself categories. Let's say a wiki devoted to educational institutions. It might makes sense to have distinct Colleges and High Schools namespaces. It makes it easier for visitors to find information in the category of interest without any authors needing to make sure that individual pages are correctly tagged. It also makes it easy to have dynamically-generated tables of contents that won't overwhelm the visitor.
A zoological wiki might have namespaces organized by taxonomy (i.e. phylum, class, order).
In our case, it seems like people are interested in having articles not just about iosmusic proper (apps, plugins, and iHardware) but also things like types of synthesis and the physics of sound.
So, it might make sense to use namespaces.
I really don’t know what these differences would look like. Could you do some minimal wiki page mock ups and post the links here so we can see?
I like option 2, but would substitute “music-knowledge” for knowledgebase.
Namespaces don't have any impact on how pages look. So, there isn't really anything to mockup. Namespaces have to do with where you put your pages. They are essentially just folders that we put the pages in.
The main thing is that when you create a page, you create it in the appropriate namespace (folder).
We wouldn't have further nesting.
If people think we need additional hierarchy (like a tutorials namespace within iosmusic), we should discuss that.
I am proposing that we don't do that and rather mark that something is a tutorial by using an appropriate tag.
I couldn't think what to call it, but I can imagine people will put stuff in there that defies categorization.
Is there a fun/good word that captures a sense of 'everything else'?
Soup?
@espiegel123 I don’t speak wiki so what you’ve written here sounds like “blah blah blah....” to me as if you were trying to explain chess to a dog and I’m the dog. If there were some page code examples or links to sites that use one approach or the other where I could look at their code, I might be able to figure out what you’re on about. Short of that, I’ll probably end up doing something wrong and get whacked with the rolled up paper when I post pages that aren’t conforming to this.
It has to do with how pages navigated to. Most people will search so it’s as much about internal house keeping as it is external discovery.
Think of a namespace as a folder. We could create a namespace called “hello” and then add a page to that name space called “world”. You could get to that page via a url like “/hello/world”. My default, the wiki will list all of the pages in a given namespace. So if we were to also add “mom” and “grandpa” to the “hello” namespace, when you navigated to “/hello” it would automatically show a list of links containing:
Don’t worry about the rolled paper. just go for it. If it needs to be moved, folks can help. No rockets will be launched so we’re good.
I like option 2. Basically as flat as possible for iosmusicstuff and some buckets for everything else. Can organize it further later if needed.
Does “Hardware” merit a namespace? Or just a single page with links?
Would be good if we could get together a solid set of base tags.
I reckon most people will just search to find stuff but I’m not sure how docuwiki does it’s search weighting, if any.
as far as “knowledgebase” items, think it might perhaps work best as a single page with headings and links (and an optional description).
If anyone has some non-iOS music thing to cover, and can cover it better than it’s already been covered elsewhere, and they don’t have a blog or something, by all means, create a page in that namespace. Otherwise, maybe a link+description is enough?
I share the same inclination about knowlegebase articles (or whatever we'll call that bucket). Some people seem inclined to want to have some sort of summary information here. But my personal inclination is to have a brief summary of those topics and links to well-done already existing sites and articles. I guess that will be an area where we see what people come up with and discuss as needed.
Should we call that namespace bucket? I kinda like that.
@syrupcore said: "Would be good if we could get together a solid set of base tags."
Want to go ahead and start a thread for that discussion?
By way of explanation about what’s been discussed about namespaces. As has been noted, a namespace is like a folder. It’s just a location where files are stored, but it also has tie-ins to automatic table of contents and a site map.
However, namespaces aren’t critical to navigation on a wiki. Wikis are primarily flexible piles of documents that can all link to one another. Anyone can create a page that references any number of other pages very, very easily. In fact, one of the ways to create pages is to create a link to the page first on another page ... before the page has even been created. Clicking the link invites one to create the page if they wish.
So, if someone creates a highly organized index page of links to pages about apps, that page can be organized, reorganized, expanded, etc, without any regard to the namespaces documents are in.
The one thing about namespaces that is important though, is it’s part of the URL for the document. So, if someone decides that a document is in the wrong namespace and moves it, guess what? Links are broken, unless things are done in specific ways. So, this is why it’s not a great idea to overly obsess about namespace structure, and to keep it simple.
Right out the gate, the wiki started to develop a bad case of namespace proliferation. So, the discussion has been around what level of namespace structure is appropriate. I say keep it simple, don’t obsess if something isn’t in the right namespace, and make sure any documents that aren’t linked to some kind of an index page (these are called orphans) get linked.
@syrupcore the only thing I would say is moving documents around isn’t really trivial. There are ways to avoid broken links internally when doing this, but external links to the page will be broken. So then there needs to be a redirect page in the old location, which to me is more messy than it’s worth. If a page is in the wrong namespace, it should probably just stay there IMO, and be linked to from a more appropriate index page instead.
Sorry, that’s all probably more confusing than it should be. I hope it makes some sense.
@wim thank you for your explanation. I’ve basically been organizing the pages I’ve posted as collections of folders with subfolders based upon categories and subcategories of content.
While this may make sense to me, I’m not sure if this is a kosher practice for wikis?
https://wiki.audiob.us/app_tutorials/Sample_Instrument/Piano_Sample_Instrument
Might be about the deepest I’ve felt the need to go. I use tags for the pages so that people can find them in ways that aren’t reflected in the directory or folder structure that I’ve used. I would say I need to get more of a hang of how many and which tags I should include. In a long page covering lots of material that’s more of a traditional linear index structure from the paper book days, there are a lot more tags as the page is functioning as a starting point for many different sources of information.
I have been avoiding lists and can see that as more detailed information is added to the wiki, such index like pages will get longer and more unwieldy. This tells me that fundamentally wikis are very different in significant ways to web pages that I’m just not fully grasping how that translates to the process of creating pages.
Should I really just be doing more focused pages, having a limited number of tags, and then let the chips fall where they may rather than resorting to old web page tree building ways? Is the more basic question on which side of the mountain I should post these more focused pages on and then resolve never to cross to the other side?
Are tags supposed to replace having more folders with sub folders inside of them? Are namespaces in wikis more like oceans rather than ponds?
@InfoCheck, I think I’ll defer to @espiegel123 for answers to your questions. My wiki knowledge is at the 60,000 foot level ... conceptual only.
But here are some opinions none the less (can’t help myself...)
In my view wikis aren’t intended to be highly structured into folders (namespaces) as you would a personal file or a web site. But I’m coming from the old-school times where wikis didn’t even have namespaces. You’d start with a page, create links to other pages of interest, and build a structure based on how you organize the content on your pages.
The downside of a deep folder/namespace structure IMO is that the path (structure) becomes the URL. The URL becomes unwieldy. The URL changes if you move the document. If there’s one designer, then maybe highly developed structure is a good thing, but if there are 100 designers all with their own idea of structure, you either get chaos, or endless discussion of how to organize things.
But ... at this point I’m kind of tired of hearing myself yammer on. If I am, then others must really be. So, I’m dropping out of the (dis)organization business. For real this time.
@wim good point about redirects. There are plugins for handling internal redirects but don't know of anything that would automagically do it for inbound links.
@espiegel123 maybe something like "non-ios" or "not-ios-specific"? Then we can reserve "knowlegebase" for something in the future.
Looks like it's already blowing up! https://wiki.audiob.us/?do=index
Generally. Since a given page might cover tips MIDI sequencing an AUV3 sampler hosted in Audiobus 3 and mixed in AUM, "categories" become hollow quickly. If you're creating your own website and controlling all of the content, a fixed structure (taxonomy/ontology) has a chance of working. With a whole bunch of user generated content... not so much.
In case it's interesting... https://en.wikipedia.org/wiki/Folksonomy#Folksonomy_vs._taxonomy
@syrupcore @wim thank you for your attempts to clarify things for me.
Wiki things I think may be relevant
hey folks. sorry i have to be super brief and hope this doesn't come across as terse.
since there seems to be a consensus around having a fairly flat structure, please don't create any more subfolders or path.
don't create overly tiny pages. for example, the stuff in the Scythe knowledgebase article should probably be one page rather than have split into several.
these are early days. i understand that some are concerned that moving pages will break the wiki because of linking from external sites. it is premature to worry about that. we can get our house in order with minimal issue. as long as we make sure pages contain the text (and tags when appropriate) that result in their showing up in a search, it is ok if the occasional page has moved without a re-direct left behind.
even wikipedia sometimes has broken links from the outside (not that we should even be thinking of wikipedia as our model since there are a lot of reasons why it doesn't fully apply). as long as the content is easy to find if a link from outside gets broken, that's ok if the content if easily found by searching. we do need to set up a good 404 redirect page (the page that comes up for "page not found"). i'll look into it and confer with @Michael about getting that setup. I think Dokuwiki has a plugin that allows that to be easily configured for the wiki. we can set one up with a nice search box or search boxes.
once we are set on our structure, we should move the pages that already exist into that structure and some people will probably need to periodically sweep through and clean it up. if we leave the existing pages that are in the wrong place as they are, it just invites people to ignore the conventions we set up.
what a wiki should bei've seen a few appeals to the notion of "what a wiki should be" -- about the only consensus that you will find among people that have a lot of experience is that there is no single correct wiki model -- just like there is no single best "reference book" model. Both the subject matter covered by a wiki and the nature of the community visiting and building the wiki influences what makes sense. appealing to early essays and writings about wikis as if they are canon is a bit like appealing to the original U.S. constitution as something to be taken literally. there is a lot that has happened since those things were written that come to bear on what makes sense for any particular wiki. So, some of those principles fully apply but some don't (in terms of structure and organization and consensus-building). so, I think it is a mistake to treat any individual wiki as being the standard model without also considering what might be different about this wiki
One question about namespaces. There seems to be an appeal to some to have "tutorials" be a category that is worth breaking out.
what do you think. should tutorials be a namespace or should we just use tags and page names to mark things as tutorials.
if you want a tutorials namespace should it be top-level or inside iosmusic?
How hard will it be to move content from an existing namespace into a newly created namespace? The one issue I have experienced is seeing a page called "timbre" and reading it disclosed a context I didn't expect. It only made sense when reached from the page that
created it and needed to define it in that context (as a concept for Animoog).
Once I understand what Namespaces offer I could see that allowing 6 versions of the "timbre" page could be offered based upon it's context. That's powerful.
Right now I think we're architecting the library and don't have any books. I can't wait for someone to make a few decisions and open the doors for works. If there are too many librarians I'll probably just write on the Forum and avoid authority. I have issues with authority and the creative act. I'm probably not unlike most artists.
If you wait for consensus you'll get committee results. I can live with any tree and find a way to work. I really don't care and will probably just wait to see some traction and then decide how to contribute.
There probably shouldn't be six different pages called "Timbre". I think this is an issue of naming conventions. No matter what conventions we set up, there will be admin work to make things work.
There will always be ongoing reorganization issues -- if you look at something that has a ton of content and large contributor base, you will see that there are some people who basically spend most of their time cleaning up pages and moving content around and getting rid of pages that duplicate other pages.
Right now, it looks like some people are using directory structures to add additional hierarchy rather than using tags or page titles. If a page is about animoog timbres, it should probably be called "Animoog Timbres" and not "Timbres" nested inside an "Animoog" namespace (directory).
One man's powerful is another's rat's nest.
If you have ever set up a large library, you know that setting up the infrastructure and deciding how you are going to organize your books is something that is useful to do before you have tons of books to re-shelve.
There may be adjustments you make, but unless you plan on having a library with 100 books, you do some planning.
My suggestion has been that as we discuss whether we are going to have some structure and what it will be to go ahead and create content at the top level.
@McD, I don’t think you need to be overly concerned about namespaces. They aren’t as important as all the discussion makes it seem. They’re largely transparent. They’re more of a way of organizing the physical content than the presentation of that content.
There is nothing to stop one creating a page called “fleas” in a namespace called “pests”, but then linking to that page on pages about Pet Grooming, Infectious Disease Control, and Circuses.
And in a Wiki, if you reached a page called Timbres and you thought it should be found in a different context, then you could edit the right page to link to the Timbre page, or create such a page yourself.
Namespaces don’t limit how content is organized as far as how it’s presented. Most people won’t ever notice them. The only way you’d ever even see it is if you looked at a URL and saw something like the “pests” part of
http://mywiki/pests/fleas
- and cared about it. Or if you were relying on the “site map” to navigate the wiki.It’s not hard to move a page. It’s literally just a matter of renaming it. But it breaks internal links unless done right, and external links possibly permanently. Fortunately, moving pages isn’t necessary in order to reorganize a wiki.
Don’t let all the intense discussion scare you away. If there’s one thing wikis are, it’s flexible. Hate the way it’s organized? Make a page called “McD’s Alternative Wiki Index” and link to it somewhere. It’s that easy.
At any rate, no matter how it’s organized, I guarantee your posts will be easier to find on the wiki than they are on the forum. Even if you just dropped them in there and put some meaningful tags on them, they’d be easily findable with the search function.
@wim , @syrupcore , @InfoCheck, @McD : after re-reading our discussions, I am coming around to a pretty minimalist approach and thinking my suggestion of a separate iosmusic and "bucket/knowledgebase" namespace is probably more hassle than it will probably be worth.
@wim made a good point about short pathnames being handy when creating new pages.
Maybe it is best to be as flat as possible. It still makes sense for me to have "user" and "wikiauthoring" (whatever it will actually be called) to be separate namespaces.
I wonder about "tutorial"? I can see pros and cons. The main pro is that it might make discoverability and indexing easier. On the other hand, it may inadvertently encourage proliferation of subdirectories.
What do you think?
+1
The more this drags on the less appealing it is to me as all I’ve received is a lot of confirmation about what I already knew, I don’t know how wiki pages are supposed to be done. Can’t there just be some example pages setup which we can use as a template for making the rest of the pages or point to a page that already has such a setup in place?
I think I'll give it a couple weeks for these decision to be made the structure. I love the freedom of the wiki as a tool and appreciate the original creators intent to give writers
a way to create organized content where the organization flows from the words used.
If a write uses [[timbre]] and the page saves with a RED link he knows he has to define the term. If it's BLUE someone has created a page. If that page fits the context it's great... if not tweak the link [[timbre_animoog]].
Editors can come along later if these rat's nests which a simply mazes of multiple paths drive them crazy. A wiki can be a maze of multiple paths that is navigated by reading. When reading you might uncover a new word and seek its meaning. A good wiki reader might add [[ ]]'s to the word and create a definition page.
Creating a community of users empowered to use the tools is actually the hardest part.
What you've created is impressive. You're work is in a clearly defined Namespace and my issue about page naming is irrelevant. If someone wants to create a page in tutorials they can take care to create suitable links to respect your existing work. It shouldn't be a problem.
A wiki page should reflect the intent of the author, IMHO. Of course, we share editing rights (until we don't which usually happens with enough users but let's try to have that problem first).
At this point I’ll post markdown pages on a thread in the knowledge base and if people here decide it’s useful to them if not, they have the ignore feature which @michael has finally broken down and given to us. If people have no use for what I do, I have no desire to foist it upon them. Clearly my naive impressions about wikis as being composed of mini web pages has been panned. When idiot proof instructions are available that I can follow, I’ll be able to fall in line but right now the line seems hazy.
I’m sorry to hear that. I hope you’ll be patient. We’re just trying to get started on the right foot. It’s only been a few days and is largely hashed out.
I think the only conceptual difference in the direction you were headed is you were thinking of the namespace tree as a navigational structure. That’s totally understandable, but maybe not the best route for a wiki. Wikis generally rely on their search engine and maybe some basic structural index pages to help people get around. Tags aid the search engine too.
As for small one-thought pages vs. several thoughts organized on a larger page, it’s not critical. I personally would rather go to one well-crafted page with a table of contents (easy to do automatically in a wiki page) than navigate a bunch of smaller pages. But that’s just me. You should create content as it works best for you.
I hope you’ll hang in there during the early pain period. You make some of the most solid contributions to the forum there are.
I have exactly the opposite idea: avoid the KB until the Wiki arrives. It's here and
there are no rules... just opinions. If @Michael changes that and wants some top down control he'll let us know.
The mic on is on. Use it and just ignore any critics. You've made some excellent progress and are a model for others. There is no wrong wiki page in a democratic system. It's free speech.
I'm not joining any committees anytime soon. But I will follow orders if someone has authority. I won't be happy and will ask for consideration but I will follow the orders.
+1
we are close to getting this all hashed out. there is nothing to prevent people from adding pages as we come up with some starting conventions. some pages may move around, but we'll make sure that they are easy to find if that happens.
@McD made a reference to author intent. The one thing about which there is some consensus across wikis, is that wikis aren't collections of personal web pages. While people should be respectful of intent, ultimately what guides development of wikis is having solid content -- which means that pages will change over time and the hope is that such changes will in the long run be for the better. But, it is by nature messy. I think one needs to let go of feelings of ownership/authorship.