The horse has already left the barn, but I just stumbled over Patterning 3's very nice manual which is done in Google Docs, and has a "Request edit access" button at the top. I hadn't thought of Google Docs as a possible solution. It seems like having a limited number of editors in a pre-published version, then turning that into a final version when desired could be pretty easy. No apps required, editable from anywhere, and somewhat controlled. Also easy to apply consistent styling.
Probably no version control or change though. Or maybe not. I haven't looked into that.
Limited formatting and managing images is always something that bothers me a little with Wikis.
I'd say that DokuWiki works quite well in these regards. Image dimensions and restrictions can be given, positioning with text seems easy to do as well.
There are a number of plugins available, e.g. for adding tagging and tag-based search functionality and overall I like the simplicity of the thing, including plain text file support that lets me format text outside DokuWiki using common commandline tools etc.
Only "Introduction" and "Modules" have any content so far, shown as green text.
It's just a first take,let's discuss structure and content!
Clicking on a link to a nonexistent page will allow you to create a new one.
Images can be uploaded too.
Make sure you read some DokuWiki docs to get an idea about formatting, tagging and linking between pages and namespaces. My focus was on the "Drambo" namespace for now.
I've installed the DokuWiki tag and tag filtering functionality so tags are supported already. Let's also discuss which tags would make the most sense, I think that modules could/should have tags different from project tags - projects might better be tagged by use case.
@rs2000 Thanks for putting all of that together so fast! I think it’s going well. First thought is the dividers on the pages are messing up the table of contents sidebar. When there is a divider there is pushes all the content down, but when there isn’t one it morphs nicely around it.
As far as module page formatting, @rec ‘s dump looked really good to me. Something like that with a more free form section bellow it for advanced analysis and or weird use cases would make the most sense.
As the module info grows, does it make the most sense to have it all on one page? I suppose that can be changed down the road though.
Also you may not have enabled it yet, but I can’t seem to edit or change anything.
As the module info grows, does it make the most sense to have it all on one page? I suppose that can be changed down the road though.
This is only one of many possible views, if I understood it correctly.
By adding tags and anchors, my idea was to make modules searchable by tags and linkable by anchors. If there's the need to split into separate pages, tht should be possible too.
I've been following this thread with interest, and the wiki seems like a great direction (thanks @rs2000 !). The top-page structure looks like a good starting point for scaffolding the rest of it in an organized manner (and probably a good template for @parkerfrost 's proposed navigation column, if/when that materializes). I will very be interested in the organizations of the top-level recipes/tips/tricks page along the same lines.
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
I'm very optimistic about this development—it's true that in-app documentation is sparse in spots, but a wiki like has the potential to go way beyond that—especially since wiki pages can hyperlink to external resources (including forums discussions like this) for further reference and nuance. And forum discussions (like this) can then link back to the articles in the wiki!
In reference to earlier discussion, I wouldn't be too concerned about lack of participation on Drambo wiki compared to fate of the AudioBus one (which it wasn't well-known or very focused)—Drambo users by their nature seem much more motivated than the general iOS music app population to work out and share details on how things work and what to do with them (and how to put that in a wiki).
It would be a very excellent feature to allow users to add their own Help text to individual Presets (ala the Library browser's "?" button), especially for Rack presets.
Over time, I forget the intended usage/quirks/etc of racks I've built or downloaded from PatchStorage. I know there are the Misc/Text Box and Misc/Section (foldable) modules, but they take up rack space and very few people have ever used them for that (and tbh, that's not where I'd expect to find Preset docs when the Drambo UI already displays module help in the Library window)
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
Trying to think of how to say this without putting anyone off. I really don't mean to discourage input of any kind, so I hope it's not taken that way.
Changing the appearance of the wiki can be done at any time, non-destructively. Changing the structure is more difficult and gets increasingly so over time. So getting started on the right foot as far as the content structure goes is far more important than style changes. As long as the content is created with consistent use of categories, tags, and heading levels, etc, putting the spit and polish on the look of it can be done site-wide and non-destructively at any time.
My only input on the structure at this time is it feels a bit monolithic. The auto generated table of contents helps a lot, but walls of text sometimes put people off, especially in this "Great, but can you make me a video?" age.
That said, splitting up a page into sub pages is better than consolidating a site with too many pages.
thanks to the plain text format, I think that splitting a structured page like the long list of modules could still be done later (by creating new separate pages where the "----" and "===== Name =====" would act as separators.
Next week, I'll play with tag based searches. Ideally, each module could have its own page and a search with all tags would return the full list of modules.
@rs2000 That sounds really good to me! Certainly a great way to get started. If we find it should be different then that changing later won’t be a huge headache.
Tag search works pretty well over on the Loopy Pro wiki ... as long as people are conscientious about tagging things.
Do tags work within pages though? I've only worked with them for finding pages, not for finding sections within pages as would be needed if larger all-inclusive pages are the norm.
I'm going to set up a local Doku Wiki here at home so I can experiment. I may pop in with some suggestions or be able to help if you run into technical questions about how to do things.
[edit] up and running in under 10 minutes. I have to say, I can tell already that Doku Wiki kicks MediaWiki's butt in terms of ease of setup, more accessible storage, and performance. 😎
@number37 Absolutely, it's really a well done solution made with love.
If tags don't work within pages, I wouldn't mind to split the respective page into separate pages with tags, hoping that I'll be able to build a search function that will present all pages that match the selected tags, as one page.
Feel free to edit on the wiki directly by the way.
I have one suggestion at this point. I think it would be more practical to at least break the main page up into separate pages at the application level - what are now the top level headings of Drambo, Sunrizer, Dagger, Zeeon, iSequence and Combustor.
You could also consider creating a sidebar page that would contain the top level links to those master pages and other high-level topics. Sidebars are handy because they're available from every page, whereas a table of contents varies unless you stick with a purely monolithic page. I think my preference is also biased just based on being used to sites having one, so you might want to ignore that suggestion.
Doku makes it simple to try out anyway. Just create the sidebar page (there's a link to it already on the doku/welcome page at install) and put some content there. You can remove the sidebar at any time by just deleting all the content in that page.
I'm only tossing out initial reactions. I'm just as happy if they're not taken up. 😎
I'll see if I can find out what plugin they use for the tag search on the AB wiki. It does list all the tag hits on one page, though not with a fully assembled page, but with only short page summaries. Tagging is done by adding the tags in a special section at the bottom of the page. Not everyone does this because it's not completely obvious how to do it.
I'm mostly holding off on editing on the live wiki until the structure is settled. The stuff I'm doing on my home wiki you wouldn't want me to mess with on your live site: experimenting with templates, plugins, style changes, etc.
https://www.dokuwiki.org/faq:sidebar has some useful information. It's pretty simple though as long as the template has builtin sidebar support (the default template and the one I mentioned via PM do). Just add content to the sidebar page and the sidebar will appear.
Comments
Great suggestions @Robin, @parkerfrost
Thank you!
modulation in drambo is really simple 😁
you just need to understand
"how to modulate anything you want to with anything you want to"
forget what the dokumentation says ;)
who cares if you are not supposed to modulate that? 😆
I dont. 😃
free your mind 😀
i do this all the time
I dont think this is anywhere in the dokumentation ?!🤔
The horse has already left the barn, but I just stumbled over Patterning 3's very nice manual which is done in Google Docs, and has a "Request edit access" button at the top. I hadn't thought of Google Docs as a possible solution. It seems like having a limited number of editors in a pre-published version, then turning that into a final version when desired could be pretty easy. No apps required, editable from anywhere, and somewhat controlled. Also easy to apply consistent styling.
Probably no version control or change though. Or maybe not. I haven't looked into that.
Limited formatting and managing images is always something that bothers me a little with Wikis.
I'd say that DokuWiki works quite well in these regards. Image dimensions and restrictions can be given, positioning with text seems easy to do as well.
There are a number of plugins available, e.g. for adding tagging and tag-based search functionality and overall I like the simplicity of the thing, including plain text file support that lets me format text outside DokuWiki using common commandline tools etc.
Works for me. I'm good with Doku or other Wikis. They're fast and efficient once you get used to them.
I just saw that Patterning 3 manual and thought "Damn, that final product looks a lot nicer than any Wiki I've come across."
Yeah, it requires quite some time and dedication to build a good manual, no matter which platform you're using.
Hi guys,
here's the first version of the Wiki.
You can log in with your forum account.
Only "Introduction" and "Modules" have any content so far, shown as green text.
It's just a first take,let's discuss structure and content!
Clicking on a link to a nonexistent page will allow you to create a new one.
Images can be uploaded too.
Make sure you read some DokuWiki docs to get an idea about formatting, tagging and linking between pages and namespaces. My focus was on the "Drambo" namespace for now.
I've installed the DokuWiki tag and tag filtering functionality so tags are supported already. Let's also discuss which tags would make the most sense, I think that modules could/should have tags different from project tags - projects might better be tagged by use case.
@rs2000 Thanks for putting all of that together so fast! I think it’s going well. First thought is the dividers on the pages are messing up the table of contents sidebar. When there is a divider there is pushes all the content down, but when there isn’t one it morphs nicely around it.
As far as module page formatting, @rec ‘s dump looked really good to me. Something like that with a more free form section bellow it for advanced analysis and or weird use cases would make the most sense.
As the module info grows, does it make the most sense to have it all on one page? I suppose that can be changed down the road though.
Also you may not have enabled it yet, but I can’t seem to edit or change anything.
What does everyone else think?
EDIT: is there a dark mode?
the colors are weird
Is there a left column hierarchal navigation system? I feel like that would help get around it quickly.
@parkerfrost
As the module info grows, does it make the most sense to have it all on one page? I suppose that can be changed down the road though.
This is only one of many possible views, if I understood it correctly.
By adding tags and anchors, my idea was to make modules searchable by tags and linkable by anchors. If there's the need to split into separate pages, tht should be possible too.
On the module page, DokuWiki has automatically created a table of contents on the right.
the colors are weird
Green: Linked page exists
Red: Linked page doesn't exist yet
I've been following this thread with interest, and the wiki seems like a great direction (thanks @rs2000 !). The top-page structure looks like a good starting point for scaffolding the rest of it in an organized manner (and probably a good template for @parkerfrost 's proposed navigation column, if/when that materializes). I will very be interested in the organizations of the top-level recipes/tips/tricks page along the same lines.
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
I'm very optimistic about this development—it's true that in-app documentation is sparse in spots, but a wiki like has the potential to go way beyond that—especially since wiki pages can hyperlink to external resources (including forums discussions like this) for further reference and nuance. And forum discussions (like this) can then link back to the articles in the wiki!
In reference to earlier discussion, I wouldn't be too concerned about lack of participation on Drambo wiki compared to fate of the AudioBus one (which it wasn't well-known or very focused)—Drambo users by their nature seem much more motivated than the general iOS music app population to work out and share details on how things work and what to do with them (and how to put that in a wiki).
On the subject on in-app documentation:
It would be a very excellent feature to allow users to add their own Help text to individual Presets (ala the Library browser's "?" button), especially for Rack presets.
Over time, I forget the intended usage/quirks/etc of racks I've built or downloaded from PatchStorage. I know there are the Misc/Text Box and Misc/Section (foldable) modules, but they take up rack space and very few people have ever used them for that (and tbh, that's not where I'd expect to find Preset docs when the Drambo UI already displays module help in the Library window)
@C__
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
Exactly my thoughts! 😊
Nonetheless, I've added a sketchpad
to add anything that comes into your mind.
It looks like a great start. 😎
Trying to think of how to say this without putting anyone off. I really don't mean to discourage input of any kind, so I hope it's not taken that way.
Changing the appearance of the wiki can be done at any time, non-destructively. Changing the structure is more difficult and gets increasingly so over time. So getting started on the right foot as far as the content structure goes is far more important than style changes. As long as the content is created with consistent use of categories, tags, and heading levels, etc, putting the spit and polish on the look of it can be done site-wide and non-destructively at any time.
My only input on the structure at this time is it feels a bit monolithic. The auto generated table of contents helps a lot, but walls of text sometimes put people off, especially in this "Great, but can you make me a video?" age.
That said, splitting up a page into sub pages is better than consolidating a site with too many pages.
Cheers @rs2000 - Happy to help out!
+ 1 on everything said here.
Great start! Thanks for getting this going.
Thanks @number37 and @offbrands,
thanks to the plain text format, I think that splitting a structured page like the long list of modules could still be done later (by creating new separate pages where the "----" and "===== Name =====" would act as separators.
Next week, I'll play with tag based searches. Ideally, each module could have its own page and a search with all tags would return the full list of modules.
But maybe there are better options?
@rs2000 That sounds really good to me! Certainly a great way to get started. If we find it should be different then that changing later won’t be a huge headache.
im color blind
green looks just like red ;)
red and green are never the colors to go for ;)
Tag search works pretty well over on the Loopy Pro wiki ... as long as people are conscientious about tagging things.
Do tags work within pages though? I've only worked with them for finding pages, not for finding sections within pages as would be needed if larger all-inclusive pages are the norm.
I'm going to set up a local Doku Wiki here at home so I can experiment. I may pop in with some suggestions or be able to help if you run into technical questions about how to do things.
[edit] up and running in under 10 minutes. I have to say, I can tell already that Doku Wiki kicks MediaWiki's butt in terms of ease of setup, more accessible storage, and performance. 😎
@number37 Absolutely, it's really a well done solution made with love.
If tags don't work within pages, I wouldn't mind to split the respective page into separate pages with tags, hoping that I'll be able to build a search function that will present all pages that match the selected tags, as one page.
Feel free to edit on the wiki directly by the way.
I have one suggestion at this point. I think it would be more practical to at least break the main page up into separate pages at the application level - what are now the top level headings of Drambo, Sunrizer, Dagger, Zeeon, iSequence and Combustor.
You could also consider creating a sidebar page that would contain the top level links to those master pages and other high-level topics. Sidebars are handy because they're available from every page, whereas a table of contents varies unless you stick with a purely monolithic page. I think my preference is also biased just based on being used to sites having one, so you might want to ignore that suggestion.
Doku makes it simple to try out anyway. Just create the sidebar page (there's a link to it already on the doku/welcome page at install) and put some content there. You can remove the sidebar at any time by just deleting all the content in that page.
I'm only tossing out initial reactions. I'm just as happy if they're not taken up. 😎
I'll see if I can find out what plugin they use for the tag search on the AB wiki. It does list all the tag hits on one page, though not with a fully assembled page, but with only short page summaries. Tagging is done by adding the tags in a special section at the bottom of the page. Not everyone does this because it's not completely obvious how to do it.
I'm mostly holding off on editing on the live wiki until the structure is settled. The stuff I'm doing on my home wiki you wouldn't want me to mess with on your live site: experimenting with templates, plugins, style changes, etc.
Thumbs up for a side bar that's available on all pages!
https://www.dokuwiki.org/faq:sidebar has some useful information. It's pretty simple though as long as the template has builtin sidebar support (the default template and the one I mentioned via PM do). Just add content to the sidebar page and the sidebar will appear.